python - 将 sys.stdout 作为参数传递给进程

Question

我将“sys.stdout”作为参数传递给一个进程，然后该进程在执行它的操作时写入“sys.stdout”。

import multiprocessing
import sys
def worker_with(stream):
    stream.write('In the process\n')

if __name__ == '__main__':
    sys.stdout.write('In the main\n')
    lock = multiprocessing.Lock()

    w = multiprocessing.Process(target=worker_with, args=(sys.stdout,))

    w.start()
    w.join()

上面的代码不起作用，它返回以下错误:“ValueError:对已关闭文件的操作”。

我尝试运行相同的代码，但直接调用该函数而不是生成一个进程并且它有效，它打印到控制台。我还尝试运行相同的代码，但在函数内部直接调用 sys.stdout，将其作为一个进程生成，并且可以正常工作。问题似乎是将 sys.stout 作为进程的参数传递。

有人知道为什么吗？

注意:此代码的灵感来自教程 PYMOTW - 进程间通信。

编辑:我在 Windows7 上运行 Python 2.7.10，32 位。

Answer 1

当您将参数传递给 Process 时，它们会在父进程中被 pickle，然后传输给子进程，然后在那里 unpickled。不幸的是，看起来通过 pickle 的往返行程对于文件对象无声地行为不端；使用协议(protocol) 0，它会出错，但是使用协议(protocol) 2(最高的 Python 2 协议(protocol)，以及用于 multiprocessing 的协议(protocol))，它会默默地产生一个垃圾文件对象:

>>> import pickle, sys
>>> pickle.loads(pickle.dumps(sys.stdout, pickle.HIGHEST_PROTOCOL))
<closed file '<uninitialized file>', mode '<uninitialized file>' at 0xDEADBEEF>

命名文件也会出现同样的问题；它不是标准 handle 所独有的。基本上，pickle 不能往返一个文件对象；即使它声称成功，结果也是垃圾。

一般来说，multiprocessing 并不真正期望处理这样的场景；通常，Processes 是辅助任务，I/O 是通过主进程执行的(因为如果它们都独立写入同一个文件句柄，就会出现交错写入问题)。

至少在 Python 3.5 中，他们修复了这个问题，所以错误是直接和明显的(open、TextIOWrapper 和 Buffered* 返回的类文件对象) ，使用任何协议(protocol) pickle 时都会出错。

您在 Windows 上能做的最好的事情就是将已知的文件描述符作为参数发送:

sys.stdout.flush()  # Precaution to minimize output interleaving
w = multiprocessing.Process(target=worker_with, args=(sys.stdout.fileno(),))

然后使用 os.fdopen 在另一侧重新打开它.对于 fd 不是标准句柄的一部分(0、1 和 2)，因为 Windows 使用“spawn"方法创建新的 Processes，你需要确保任何这样的 fd 都是由于 import __main__ 模块 when __name__ != "__main__"(Windows 通过导入 __main__ 模块模拟一个 fork，设置 __name__ 到其他东西)。当然，如果它是一个命名文件，而不是标准句柄，您可以只传递名称并重新打开它。例如，要使其正常工作，您需要更改:

def worker_with(stream):
    stream.write('In the process\n')

到:

import os

def worker_with(toopen):
    opener = open if isinstance(toopen, basestring) else os.fdopen
    with opener(toopen, 'a') as stream:
        stream.write('In the process\n')

注意:如所写，如果 fd 用于标准句柄之一，os.fdopen 将关闭底层文件描述符with 语句退出，这可能不是您想要的。如果您需要文件描述符在 with block 结束后仍然存在，当传递文件描述符时，您可能需要使用 os.dup在调用 os.fdopen 之前复制句柄，因此这两个句柄相互独立。

其他解决方案包括通过 multiprocessing.Pipe 将结果写回主进程(因此主进程负责将数据传递到 sys.stdout，可能启动一个线程以异步执行此工作)，或使用更高级别的构造(例如 multiprocessing.Pool().*map*)使用 return 语句而不是返回数据显式文件 I/O。

如果你真的急于让所有文件描述符都通用(并且不关心可移植性)，而不仅仅是在 的 import 上创建的标准句柄和描述符__main__，你可以使用the undocumented Windows utility function multiprocessing.forking.duplicate用于显式地将文件描述符从一个进程复制到另一个进程；这将是令人难以置信的 hacky(你需要查看 multiprocessing.forking.Popen 的 Windows 定义的其余部分以了解如何使用它)，但它至少允许传递任意文件描述符，而不仅仅是静态打开的文件描述符。