如果创建了multiprocessing.Pool,Python子进程wait()将失败

2019年8月4日 262次阅读

在一个使用subprocess到gzip输出的简单脚本中(使用subprocess.PIPE到外部命令的stdin),如果在创建子进程和关闭进程的stdin之间创建了multiprocessing.Pool对象,则subprocess.wait ()将永远挂起.

import multiprocessing
import subprocess

proc = subprocess.Popen(["gzip", "-c", "-"], 
                        stdout=open('filename', 'w'), stdin=subprocess.PIPE)
multiprocessing.Pool()
proc.stdin.close()
proc.wait()

移动multiprocessing.Pool调用一行或一行调用可以防止出现问题.

我在Python 2.7.3(Linux)和Python 2.7.1(OS X)上遇到过这种情况.

显然,这是一个微不足道的例子 – 真正的用法要复杂得多.我也已经知道GzipFile了 – 我宁愿不使用它;使用子进程可以通过将gzipping分成单独的线程来获得更多的CPU使用率.

我看不出简单地实例化Pool应该如何产生这种影响.

最佳答案 当您调用multiprocessing.Pool时,多处理模块会创建几个新进程(使用os.fork或类似的进程).

默认情况下,在fork期间,新进程会继承所有打开的文件描述符.

当您使用subprocess.PIPE参数调用subprocess.Popen时,子流程模块会创建一些新的管道文件描述符,以便向/从新进程发送数据.在这种特殊情况下,管道用于将数据从父进程(python)发送到子进程(gzip),并且gzip将退出 – 从而使proc.wait()完成 – 当对管道的所有写访问权限进行时远. (这是在管道上生成“EOF”的原因：该管道不再存在可写入的文件描述符.)

因此,在这种情况下,如果您(所有在“原始”python进程中)按此顺序执行此操作：

>创建一个管道
>创建一些multiprocessing.Pool流程
>将数据发送到gzip
>关闭管道以gzip

然后,由于fork的行为,每个Pool进程都有一个写入gzip管道的os.dup,因此gzip继续等待更多数据,这些池进程可以(但从不这样做)发送.一旦Pool进程关闭其管道描述符,gzip进程就会退出.

将其修复为真实(更复杂)的代码可能非常重要.理想情况下,您希望多处理.Pool(知道,不知何故)应该保留哪些文件描述符,哪些不应该保留,但这并不像“只是在创建的子进程中关闭一堆描述符”那么简单：

output = open('somefile', 'a')
def somefunc(arg):
    ... do some computation, etc ...
    output.write(result)
pool = multiprocessing.Pool()
pool.map(somefunc, iterable)

显然,output.fileno()必须由工作进程共享.

您可以尝试使用Pool的初始化程序来调用proc.stdin.close(或在fd列表中的os.close),但是您需要安排跟踪描述符到关闭.重构代码可能最简单,以避免“在错误的时间”创建池.

点赞