Python 子进程在接收 stdin EOF 时遇到神秘延迟
我将应用程序中遇到的问题简化为以下测试用例。在此代码中,父进程同时生成 2 个(您可以生成更多)子进程,这些子进程通过 stdin 从父进程读取一条大消息,休眠 5 秒,然后写回一些内容。但是,某处发生了意外的等待,导致代码在 10 秒内完成,而不是预期的 5 秒。
如果设置 verbose=True ,您可以看到落后的子进程正在接收大部分消息,然后等待最后一个 3 个字符块——它没有检测到管道已关闭。此外,如果我对第二个进程不执行任何操作 (doreturn=True
),则第一个进程将永远看到 EOF。
有什么想法发生了什么吗?再往下是一些示例输出。提前致谢。
from subprocess import *
from threading import *
from time import *
from traceback import *
import sys
verbose = False
doreturn = False
msg = (20*4096+3)*'a'
def elapsed(): return '%7.3f' % (time() - start)
if sys.argv[1:]:
start = float(sys.argv[2])
if verbose:
for chunk in iter(lambda: sys.stdin.read(4096), ''):
print >> sys.stderr, '..', time(), sys.argv[1], 'read', len(chunk)
else:
sys.stdin.read()
print >> sys.stderr, elapsed(), '..', sys.argv[1], 'done reading'
sleep(5)
print msg
else:
start = time()
def go(i):
print elapsed(), i, 'starting'
p = Popen(['python','stuckproc.py',str(i), str(start)], stdin=PIPE, stdout=PIPE)
if doreturn and i == 1: return
print elapsed(), i, 'writing'
p.stdin.write(msg)
print elapsed(), i, 'closing'
p.stdin.close()
print elapsed(), i, 'reading'
p.stdout.read()
print elapsed(), i, 'done'
ts = [Thread(target=go, args=(i,)) for i in xrange(2)]
for t in ts: t.start()
for t in ts: t.join()
输出示例:
0.001 0 starting
0.003 1 starting
0.005 0 writing
0.016 1 writing
0.093 0 closing
0.093 0 reading
0.094 1 closing
0.094 1 reading
0.098 .. 1 done reading
5.103 1 done
5.108 .. 0 done reading
10.113 0 done
如果有影响的话,我正在使用 Python 2.6.5。
I reduced a problem I was seeing in my application down into the following test case. In this code, a parent process concurrently spawns 2 (you can spawn more) subprocesses that read a big message from the parent over stdin, sleep for 5 seconds, and write something back. However, there's unexpected waiting happening somewhere, causing the code to complete in 10 seconds instead of the expected 5.
If you set verbose=True
, you can see that the straggling subprocess is receiving most of the messages, then waiting for the last chunk of 3 chars---it's not detecting that the pipe has been closed. Furthermore, if I simply don't do anything with the second process (doreturn=True
), the first process will never see the EOF.
Any ideas what's happening? Further down is some example output. Thanks in advance.
from subprocess import *
from threading import *
from time import *
from traceback import *
import sys
verbose = False
doreturn = False
msg = (20*4096+3)*'a'
def elapsed(): return '%7.3f' % (time() - start)
if sys.argv[1:]:
start = float(sys.argv[2])
if verbose:
for chunk in iter(lambda: sys.stdin.read(4096), ''):
print >> sys.stderr, '..', time(), sys.argv[1], 'read', len(chunk)
else:
sys.stdin.read()
print >> sys.stderr, elapsed(), '..', sys.argv[1], 'done reading'
sleep(5)
print msg
else:
start = time()
def go(i):
print elapsed(), i, 'starting'
p = Popen(['python','stuckproc.py',str(i), str(start)], stdin=PIPE, stdout=PIPE)
if doreturn and i == 1: return
print elapsed(), i, 'writing'
p.stdin.write(msg)
print elapsed(), i, 'closing'
p.stdin.close()
print elapsed(), i, 'reading'
p.stdout.read()
print elapsed(), i, 'done'
ts = [Thread(target=go, args=(i,)) for i in xrange(2)]
for t in ts: t.start()
for t in ts: t.join()
Example output:
0.001 0 starting
0.003 1 starting
0.005 0 writing
0.016 1 writing
0.093 0 closing
0.093 0 reading
0.094 1 closing
0.094 1 reading
0.098 .. 1 done reading
5.103 1 done
5.108 .. 0 done reading
10.113 0 done
I'm using Python 2.6.5 if that makes a difference.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
经过太多时间,在引用 这篇文章后,我想通了 向我跳来:
我应该知道这一点,但我从来没有想到过 - 与 Python 特别无关。发生的事情是:子进程被分叉了打开(写入器)彼此管道的文件描述符。只要管道有打开的写入器文件描述符,读取器就不会看到 EOF。
例如:
close_fds
参数。 >Popen,所以解决方案是传递close_fds=True
。事后看来,所有这些都很简单明了,但仍然花费了至少几个眼球的时间。After way too much time, I figured it out, after a quote from this post jumped out at me:
I should've known this, but it never occurred to me - had nothing to do with Python in particular. What was happening was: the subprocesses were getting forked with open (writer) file descriptors to each others' pipes. As long as there are open writer file descriptors to a pipe, readers won't see EOF.
E.g.:
Turns out there's a
close_fds
parameter toPopen
, so the solution is to passclose_fds=True
. All simple and obvious in hindsight, but still managed to cost at least a couple eyeballs good chunks of time.