python - 当 multiprocessing 使用 fork 作为起始方法时，为什么传递给 Pool.map 的函数会被 pickle ？

Question

在 Linux 中，multiprocesing 模块使用 fork 作为新进程的默认启动方法。为什么有必要对传递给 map 的函数进行 pickle ？据我了解，流程的所有状态都已克隆，包括功能。我可以想象，如果使用 spawn 而不是 fork，为什么这是必要的。

Answer 1

.map() 之类的作业方法不会启动 新进程，因此此时利用 fork 不是一个选项。 Pool 使用 IPC 将参数传递给已经运行的工作进程，这总是需要序列化(pickling)。不过，似乎对这里的 pickle 涉及的内容存在更深层次的误解。

当您查看像 .map() 这样的作业方法时，此处对函数的 pickling 只会导致合格的函数名称作为字符串发送，而 unpickling 期间的接收过程基本上只是看起来在其全局范围内上调函数以再次引用它。

现在在 spawn 和 fork 之间有一个区别，但是一旦工作进程启动(从初始化 Pool 开始)，它就已经具体化了。使用 spawn-context，新工作人员需要从头开始构建所有可达的全局对象，使用 fork 它们已经存在。因此，当您使用 fork 时，您的函数将在启动期间被克隆一次，这将节省一点时间。

当您稍后开始发送作业时，在工作程序中取消选中您发送的函数，在任何上下文中，都意味着再次从全局范围重新引用该函数。这就是为什么该函数需要在您实例化池和启动 worker 之前存在，即使是与 spawn-context 一起使用也是如此。

因此，您可能会遇到无法 pickle 本地或未命名函数 (lambdas) 的不便，其根源在于重新获得对工作进程中(当时)已经存在的函数的引用的问题。如果之前使用 spawn 或 fork 设置工作进程，此时没有区别。