多处理forkvs spawn

如何解决多处理forkvs spawn

我正在从python doc中阅读两者的描述：

生成

父进程将启动一个全新的python解释器进程。子进程将仅继承运行进程对象run（）方法所需的那些资源。特别是，父进程中不必要的文件描述符和句柄将不会被继承。与使用fork或forkserver相比，使用此方法启动进程相当慢。 [在Unix和Windows上可用。 Windows和macOS上的默认设置。]

叉子

父进程使用os.fork（）派生Python解释器。子进程开始时实际上与父进程相同。父进程的所有资源均由子进程继承。请注意，安全地分叉多线程进程是有问题的。 [仅在Unix上可用。 Unix上的默认设置。]

我的问题是：

1. 分叉是否快得多，因为它不会尝试识别要复制的资源？
2. 是不是因为fork复制了所有内容，与spawn（）相比，它会“浪费”更多的资源？

解决方法

在 3 multiprocessing start methods 之间有一个权衡：

1. fork 速度更快，因为它对父进程的整个虚拟内存进行写时复制，包括初始化的 Python 解释器、加载的模块和内存中构造的对象。

   但是 fork 不会复制父进程的线程。因此，在父进程中由其他线程持有的锁（在内存中）被卡在子进程中而没有拥有线程来解锁它们，当代码试图获取它们中的任何一个时，准备好导致死锁。此外，任何带有分叉线程的本机库都将处于损坏状态。

   复制的 Python 模块和对象可能有用，或者它们可能不必要地使每个分叉的子进程膨胀。

   子进程还“继承”操作系统资源，例如打开的文件描述符和打开的网络端口。这些也可能导致问题，但 Python 可以解决其中的一些问题。

   所以fork 速度快、不安全，而且可能很臃肿。

   但是，这些安全问题可能不会造成麻烦，具体取决于子进程的作用。

2. spawn 从头开始​​一个 Python 子进程，没有父进程的内存、文件描述符、线程等。从技术上讲，spawn fork 当前进程的副本，然后子进程立即调用exec 用新的 Python 替换自身，然后要求 Python 加载目标模块并运行目标可调用。

   因此spawn 是安全、紧凑且速度较慢的，因为 Python 必须加载、初始化自身、读取文件、加载和初始化模块等。

   但是，与子进程所做的工作相比，它可能不会明显变慢。

3. forkserver 分叉当前 Python 进程的副本，该副本将缩减为近似全新的 Python 进程。这成为“分叉服务器”过程。然后每次启动子进程时，它都会要求 fork 服务器 fork 一个子进程并运行其目标可调用。

   那些子进程一开始都是紧凑的，没有卡住的锁。

   forkserver 更复杂，而且没有很好的文档记录。 Bojan Nikolic's blog post 详细介绍了 forkserver 及其用于预加载某些模块的秘密 set_forkserver_preload() 方法。小心使用未记录的方法，尤其是。在 bug fix in Python 3.7.0 之前。

   所以forkserver 是快速、紧凑且安全的，但它更复杂且没有很好的文档记录。

[文档在所有这些方面都不是很好，所以我结合了来自多个来源的信息并做出了一些推论。对任何错误发表评论。]

,

1. 分叉是否快得多，因为它不会尝试识别要复制的资源？

是的，速度更快。内核可以克隆整个过程，并且仅复制修改的内存页作为一个整体。无需将资源用于新进程并从头启动解释器。

1. 是不是因为fork复制了所有内容，与spawn（）相比，它会“浪费”更多的资源？

现代内核上的前叉仅执行"copy-on-write"，并且仅影响实际更改的内存页面。需要注意的是，“写入”已经仅包含对CPython中的对象进行迭代。那是因为对象的引用计数增加了。

如果您的进程运行很长时间，并且正在使用许多小对象，则这可能意味着您浪费了比spawn更多的内存。有趣的是，我记得Facebook声称通过将Python进程从“ fork”切换为“ spawn”，内存使用量大大减少了。