问题 是subprocess.Popen不是线程安全的吗?


以下简单脚本会间歇性地挂起subprocess.Popen(大约30%的时间)。
除非use_lock = True,然后它永远不会挂起,导致我相信子进程不是线程安全的! 预期的行为是脚本在5-6秒内完成。
为了演示这个bug,只需运行几次“python bugProof.py”直到它挂起。 Ctrl-C退出。你会看到'后Popen'只出现一次或两次,但不是第三次出现。

import subprocess, threading, fcntl, os, time
end_time = time.time()+5
lock = threading.Lock()
use_lock = False
path_to_factorial = os.path.join(os.path.dirname(os.path.realpath(__file__)),'factorial.sh')

def testFunction():
    print threading.current_thread().name, '| pre-Popen'
    if use_lock: lock.acquire()
    p = subprocess.Popen([path_to_factorial], stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
    if use_lock: lock.release()
    print threading.current_thread().name, '| post-Popen'
    fcntl.fcntl(p.stdout, fcntl.F_SETFL, os.O_NONBLOCK)
    fcntl.fcntl(p.stderr, fcntl.F_SETFL, os.O_NONBLOCK)
    while time.time()<end_time:
        try: p.stdout.read()
        except: pass
        try: p.stderr.read()
        except: pass
    print threading.current_thread().name, '| DONE'

for i in range(3):
    threading.Thread(target=testFunction).start()


上面引用的shell脚本(factorial.sh):

#!/bin/sh
echo "Calculating factorial (anything that's somewhat compute intensive, this script takes 3 sec on my machine"
ans=1
counter=0
fact=999
while [ $fact -ne $counter ]
do
    counter=`expr $counter + 1`
    ans=`expr $ans \* $counter`
done
echo "Factorial calculation done"
read -p "Test input (this part is critical for bug to occur): " buf
echo "$buf"

系统信息: Linux 2.6.32-358.123.2.openstack.el6.x86_64#1 SMP Thu Sep 26 17:14:58 EDT 2013 x86_64 x86_64 x86_64 GNU / Linux
Python 2.7.3(默认,2013年1月22日,11:34:30)
[bCC 4.4.6 20120305(Red Hat 4.4.6-4)]在linux2上


12058
2018-01-17 19:36


起源

在Popen调用中设置close_fds = True也可以解决问题。 - Roman
这实际上是我最近在Python中遇到的最令人生气的事情。太令人沮丧了。 - Mark Roberts


答案:


在Python 2.x上,存在影响subprocess.Popen的各种竞争条件。 (例如,在2.7上它会禁用和恢复垃圾收集以防止各种时序问题,但这本身并不是线程安全的)。参见例如 http://bugs.python.org/issue2320http://bugs.python.org/issue1336 和 http://bugs.python.org/issue14548 针对该领域的一些问题。

在Python 3.2中对子进程进行了实质性的修改,它解决了这些问题(除其他外,fork和exec代码在C模块中,而不是在fork和exec之间的关键部分中执行一些合理的Python代码),并且可用向后移植到最近的Python 2.x版本中 subprocess32 模块。请注意PyPI页面中的以下内容:“在POSIX系统上,当在线程应用程序中使用时,它保证可靠。”

我可以重现上面代码的偶然事件(约占我25%),但是在使用之后 import subprocess32 as subprocess 我在100多次跑步中没有看到任何失败。

请注意,subprocess32(和Python 3.2+)默认为close_fds = True,但是在使用subprocess32的情况下,即使使用close_fds = False,我也没有看到任何失败(不是说你应该通常需要它)。


13
2017-08-08 22:33