c - 大规模 Unix C 应用程序中 fork 进程的持续时间和范围

Question

我们在学校处理 Unix 系统上的 C 代码，我们想要 fork 进程以将应用程序拆分为多个进程。寻求有关 fork 工作原理的概念性帮助。

例如，我了解到当您 fork() 时，会创建一个新的 [子] 进程，其内存空间与父进程相同(共享内存除外)。在这种情况下，“父进程”是什么？在操作系统将应用程序分解为更小的进程之前，有多少代码库被打包到一个给定的进程中？还是我对“流程”的理解全错了？

例如，如果您有一个 100,000 行的程序，在第 70,000 行的某处调用了 fork()，那么整个程序和在应用程序运行时构建的内存是否会重复，即使只有一小部分 parent 的数据对于 child 的成功是必要的吗？像这样的大型程序是否会拆分成较小的进程以减轻 fork() 调用的重复负载？如果是这样， split 在哪里？如果没有，你如何围绕这个进行优化？应用程序一开始不应该这么大吗？

一个类似的问题，当创建了一个与父进程相同的子进程时，什么时候可以假定它被终止？使用上面的 100,000 行程序示例，如果在第 100 行有一个 fork ，即使不需要， fork 的 child 是否会运行整个程序的其余部分？你怎么能避免这种情况？是否有我们类没有深入研究的设计因素？我们生活在一个学术代码库中，我们所有的程序都在 50 行或更少，但我正在努力学习大局概念以启发我。

谢谢!

Answer 1

您对 fork() 的理解是完全正确的 - 它应该执行调用进程的精确副本，有效地使程序的内存需求加倍。

在实践中(如果使用得当)，在大多数现代操作系统的虚拟内存实现的帮助下，大部分开销都被优化掉了:首先，操作系统只会考虑用于复制的可写段(文本段 - 你的代码 - 不是被认为在大多数操作段上是可写的)，因此两个进程将共享相同的代码段。对于剩余的数据段，操作系统将在写入时进行复制，因此数据段只会在 child 首次尝试写入时复制。

数据段的复制将逐页完成，因此对于分散在页面上的父数据和子数据的“不太巧妙的混合”，您仍然可以强制复制大部分父数据未使用到 child 的内存空间。使用经典的 fork()- exec() 对，大部分数据将被有效分离。