Python子进程在接收stdin EOF时会遇到神秘的延迟

Question

我将我在应用程序中看到的问题减少到下面的测试用例中.在此代码中,父进程同时生成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.

Answer 1

经过太多时间后,我想出来了,在这篇文章引用了我之后:

请参阅管道(7)中的"管道和FIFO上的I/O"部分("man 7 pipe")

"如果所有引用管道写入端的文件描述符都已关闭,那么从管道读取(2)的尝试将看到文件结束(read(2)将返回0)."

我应该知道这一点,但我从未想过 - 特别是与Python无关.发生的事情是:子进程正在分配开放(编写器)文件描述符到彼此的管道.只要管道中有开放的编写器文件描述符,读者就不会看到EOF.

例如:

p1=Popen(..., stdin=PIPE, ...) # creates a pipe the parent process can write to
p2=Popen(...) # inherits the writer FD - as long as p2 exists, p1 won't see EOF

原来有一个close_fds参数Popen,所以解决方案是通过close_fds=True.事后看来,这一切都很简单明了,但仍然设法花费了至少几个眼球好时间.