以下简单的脚本暂停在子进程上.Popen调用间歇性(大约30%的时间).
除非use_lock = True,否则它永远不会挂起,导致我相信子进程不是线程安全的!
预期的行为是脚本在5-6秒内完成.
为了演示错误,只需运行“ python bugProof.py”,直到挂起. Ctrl-C退出.你会看到’post-popen’只出现一次或两次,但不是第三次.
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)
[GCC 4.4.6 20120305(Red Hat 4.4.6-4)]在linux2上
除非use_lock = True,否则它永远不会挂起,导致我相信子进程不是线程安全的!
预期的行为是脚本在5-6秒内完成.
为了演示错误,只需运行“ python bugProof.py”,直到挂起. Ctrl-C退出.你会看到’post-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,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()@H_404_7@上面引用的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"@H_404_7@系统信息:
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)
[GCC 4.4.6 20120305(Red Hat 4.4.6-4)]在linux2上
解决方法
在Python 2.x上,有各种竞争条件影响subprocess.Popen. (例如,在2.7它禁用和恢复垃圾回收以防止各种计时问题,但这本身不是线程安全的).参见例如
http://bugs.python.org/issue2320,http://bugs.python.org/issue1336和
http://bugs.python.org/issue14548在这方面的一些问题.
@H_404_7@在Python 3.2中对Python进行了大量的修改,它解决了这些问题(除了别的以外,fork和exec代码在C模块中,而不是在fork和exec之间的关键部分中进行了一些合理的Python代码),而且可用于subprocess32模块中最近的Python 2.x版本.请注意PyPI页面中的以下内容:“在POSIX系统上,在线程应用程序中使用时可保证其可靠”.
@H_404_7@我可以重现偶然的(约25%的我)崩溃的上面的代码,但使用import subprocess32作为子进程,我没有看到任何失败在100运行.
@H_404_7@请注意,subprocess32(和Python 3.2)默认为close_fds = True,但是使用subprocess32,即使close_fds = False也不会发生任何故障(而不是您一般需要的).