c - C : fork or fork + exec 中多处理应用程序的体系结构

Question

我的问题是关于哲学而非技术问题。

目标是编写一个具有一个“主”进程和 N 个“工作”进程的多进程(不是多线程)程序。程序是仅限 linux 的、异步的、基于事件的 Web 服务器，如 nginx。因此，主要问题是如何生成“工作”进程。

在 linux 世界中有两种方式:

1). fork()

2). fork() + exec*()家庭

每种方式的简短描述以及每种方式中让我感到困惑的地方。

第一种方式 fork()是脏的，因为 fork 进程具有父内存的副本(...写时，我知道):信号处理程序、变量、文件\套接字描述符、环境和其他，例如堆栈和堆。总之，在 fork 之后我需要......嗯......“清除内存”，例如，禁用信号处理程序，套接字连接和其他可怕的事情，从 parent 那里继承，因为 child 有很多他不想要的数据- 破坏封装，可能会产生许多副作用。

这种情况的一般方法是在 fork 进程中运行无限循环来处理一些数据，并在 fork() 之前和之后使用套接字对、管道或共享内存来创建父子之间的通信 channel 。 ，因为套接字描述符在子级中重新打开并使用与父级相同的套接字。

此外，这是 nginx 方式:它有一个可执行二进制文件，使用 fork()用于生成子进程。

第二种方式与第一种方式类似，但与exec*()的用法不同。 fork() 之后子进程中的函数用于运行外部二进制文件。一件重要的事情是 exec*()在当前( fork 的)进程内存中加载二进制文件，自动清除堆栈、堆并执行所有其他讨厌的工作，因此 fork 看起来就像一个全新的程序实例，没有父内存或其他垃圾的副本。

在父子之间建立通信还有另一个问题:因为在exec*() 之后 fork 了进程。删除从父级继承的所有数据，我需要以某种方式在父级和子级之间创建一个套接字对。例如，在父级中创建额外的监听套接字(域或在另一个端口中)并等待子级连接，子级应在初始化后连接到父级。

第一种方法很简单，但是让我很困惑，那不是一个清晰的进程，只是父内存的一个副本，有很多可能的副作用和垃圾，需要记住，forked 进程对父进程有很多依赖代码。第二种方式需要更多时间来支持两个二进制文件，并且不像单文件解决方案那样优雅。也许，最好的方法是使用 fork()用于进程创建和清除它的内存而不需要 exec*()打电话，但我找不到第二步的任何解决方案。

总而言之，我需要帮助来决定使用哪种方式:创建像 nginx 这样的单文件可执行文件，然后使用 fork() ，或创建两个单独的文件，一个包含“server”，一个包含“worker”，然后使用 fork() + exec*(worker)来自“服务器”N 次，想知道每种方式的优缺点，也许我错过了什么。

Answer 1

对于多进程解决方案，fork 和 fork+exec 这两个选项几乎是等效的，并且取决于子进程和父进程上下文。如果子进程执行父进程的文本(二进制)并需要全部或部分父进程(描述符、信号等)——这是使用 fork 的标志。如果 child 应该执行一个新的二进制文件并且不需要 parent 的工作人员的任何东西 - 似乎 fork+exec 更合适。

pthread库中还有一个很好的函数——pthread_atfork()。它允许注册将在 fork 之前和之后调用的处理程序。这些处理程序可以执行所有必要的工作(例如，关闭文件描述符)。