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

我将应用程序中遇到的问题简化为以下测试用例。在此代码中，父进程同时生成 2 个（您可以生成更多）子进程，这些子进程通过 stdin 从父进程读取一条大消息，休眠 5 秒，然后写回一些内容。然而，某处发生了意外的等待，导致代码在 10 秒内完成，而不是预期的 5 秒。

如果你设置verbose=True，您可以看到落后的子进程正在接收大部分消息，然后等待最后 3 个字符块——它没有检测到管道已关闭。此外，如果我对第二个过程不做任何事情（doreturn=True），第一个过程将never见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，如果这有什么区别的话。

经过太多时间后，我在引用了这个帖子向我跳出来：

请参阅 pipeline(7) 的“管道和 FIFO 上的 I/O”部分（“man 7 pipeline”）

“如果所有引用管道写入端的文件描述符都有 已关闭，然后尝试从管道读取（2）将看到 文件结尾（read(2) 将返回 0）。”

我应该知道这一点，但我从来没有想到过——与 Python 特别无关。发生的情况是：子进程通过打开（编写器）文件描述符到彼此的管道进行分叉。只要管道有打开的写入器文件描述符，读取器就不会看到 EOF。

E.g.:

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。事后看来，一切都简单明了，但仍然花费了至少几个眼球的大量时间。