当前位置：首页 > news >正文

C++父子进程通信：从匿名管道到本地套接字的实战指南

news 2026/7/14 6:19:42

1. 项目概述：为什么父子进程通信是C++开发者的必修课

在C++的世界里，尤其是涉及系统编程、高性能服务器开发或者需要执行外部命令的场景，你迟早会遇到一个核心问题：如何让一个“父进程”和它亲手创建的“子进程”说上话？这不仅仅是让两个程序模块交换数据那么简单，它关乎资源管理、错误处理乃至整个应用的稳定性。想象一下，你写了一个下载管理器（父进程），它需要调用一个外部的、用C++写的文件校验工具（子进程）。父进程把文件路径告诉子进程，子进程计算完MD5或SHA256后，再把结果“回传”给父进程。这个过程，就是父子进程通信（Inter-Process Communication between Parent and Child Processes）的典型场景。

我见过不少新手开发者，一上来就用最“粗暴”的方式——让子进程把结果写入一个临时文件，父进程再去读。这方法不是不行，但在高并发、需要实时响应的场景下，文件I/O的延迟和潜在的锁竞争会成为性能瓶颈，更别提临时文件管理带来的繁琐和安全隐患。因此，深入理解并掌握几种高效、可靠的进程间通信（IPC）机制，是每个希望进阶的C++开发者必须跨过的门槛。今天，我们就抛开那些笼统的概念，直接深入到代码层面，聊聊在Linux/Unix-like系统（这也是C++系统编程的主战场）上，如何用C++标准库和系统调用，实实在在地实现父子进程间的“对话”。

2. 核心通信机制深度解析与选型考量

在动手写代码之前，我们必须搞清楚手上有哪些“工具”，以及每种工具最适合什么“活儿”。父子进程通信，本质上是两个具有亲缘关系的独立内存空间之间的数据交换。由于内存隔离，它们不能像线程那样直接共享变量，必须通过操作系统提供的机制。下面这几种是实践中最高频、最实用的。

2.1 匿名管道：单向数据流的经典实现

管道（Pipe），特别是匿名管道，是父子进程通信最原始也最经典的模型。你可以把它想象成一段连接两个进程的“水管”，数据像水一样从一端流入，从另一端流出。但关键点在于，这根“水管”是单向的。

它的创建和使用非常直接：

#include <unistd.h> int pipe(int pipefd[2]);

系统调用pipe会创建一对文件描述符：pipefd[0]用于读，pipefd[1]用于写。数据从pipefd[1]写入，从pipefd[0]读出。在调用fork()创建子进程后，父子进程会各自继承这对打开的文件描述符。为了实现通信，通常需要关闭不用的那一端。例如，父进程想向子进程发送数据，那么父进程会关闭读端（pipefd[0]），子进程关闭写端（pipefd[1]）。

注意：管道的数据是字节流，没有消息边界。这意味着如果你先后写入“Hello”和“World”，读取端可能一次读到“HelloWorld”，也可能分两次“Hello”和“World”读到。应用层需要自己定义协议（比如在每个消息前加长度头）来区分消息。

管道有一个隐含的缓冲区（通常大小是64KB），当缓冲区满时，写操作会阻塞；当缓冲区空时，读操作会阻塞。这种阻塞特性使得管道天然适合用于生产-消费模型。

选型考量：匿名管道简单、高效，是单向通信和实现类似shell中“|”管道符功能的首选。但它有两个主要限制：一是只能用于有亲缘关系的进程（通常是父子）；二是通信方向固定，若要双向通信，需要建立两个管道，增加了管理的复杂度。

2.2 命名管道：突破亲缘关系的壁垒

匿名管道没有名字，只能通过继承文件描述符的方式使用，这限制了它的使用范围。命名管道（Named Pipe 或 FIFO）则通过文件系统中的一个特殊文件（FIFO文件）来标识，任何知道其名称的进程都可以打开它进行通信，从而突破了亲缘关系的限制。

在Shell中，你可以用mkfifo命令创建一个FIFO文件。在C++中，使用mkfifo()系统调用。

#include <sys/types.h> #include <sys/stat.h> int mkfifo(const char *pathname, mode_t mode);

创建后，进程可以像操作普通文件一样用open()、read()、write()、close()来操作它。对于父子进程通信，虽然我们更多用匿名管道，但理解命名管道很重要，因为它是理解更广义IPC的基础，并且当你的架构演变为多个独立进程需要协作时，FIFO会是一个备选方案。

选型考量：命名管道提供了持久的通信节点，允许无亲缘关系的进程通信。但它仍然是单向的。虽然可以通过打开两次（一次只读，一次只写）来模拟双向，但这不是它的标准用法且容易出错。在纯粹的父子进程场景下，匿名管道通常更轻量、更方便。

2.3 共享内存：极致性能的代价

当通信的数据量非常大，或者对延迟极其敏感时，管道（涉及内核缓冲区的拷贝）的性能开销可能成为瓶颈。这时，共享内存（Shared Memory）就是“杀手锏”。它允许两个或多个进程共享同一块物理内存区域，一个进程写入的数据，另一个进程立即可见，省去了内核态和用户态之间的数据拷贝，速度最快。

在POSIX标准中，我们使用shm_open()、ftruncate()、mmap()这一套组合拳来创建和映射共享内存对象。过程比管道繁琐：

shm_open()：创建或打开一个共享内存对象，得到一个文件描述符。
ftruncate()：设置这个共享内存对象的大小。
mmap()：将共享内存对象映射到进程的虚拟地址空间，获得一个可操作的指针。
父子进程（或其他进程）通过指针直接读写该内存。

选型考量：共享内存提供了无与伦比的性能。但是，能力越大，责任越大。共享内存不提供任何同步机制。当父进程和子进程同时读写同一块区域时，会产生竞态条件（Race Condition），导致数据不一致。因此，使用共享内存必须搭配进程间同步原语，如信号量（Semaphore）或互斥锁（Mutex，但需要放在共享内存中并设置为进程间共享属性）。这引入了显著的复杂度和死锁风险。所以，除非你确实被性能问题逼得走投无路，并且对并发控制有深刻理解，否则在父子进程通信中应谨慎使用共享内存。

2.4 信号：简单事件通知

信号（Signal）是一种异步通信机制，用于通知进程某个事件已经发生。它传输的信息量非常小，本质上就是一个整数编号（如SIGINT表示中断，SIGUSR1和SIGUSR2是留给用户自定义的）。

父进程可以通过kill()系统调用向子进程发送信号，子进程也可以通过kill()向父进程发送（前提是知道父进程的PID）。进程可以使用sigaction()系统调用来为特定信号安装处理函数。

选型考量：信号不适合传输实际数据，它只是一个“通知”。常用于控制流程，比如父进程通知子进程“优雅退出”（发送SIGTERM），或者子进程通知父进程“我完成了某项任务”。由于信号处理函数的执行上下文特殊（异步中断），在其中能安全调用的函数非常有限，编写复杂的信号处理逻辑很容易引入难以调试的Bug。

2.5 本地套接字：全能但稍重

Unix Domain Socket（本地套接字）是另一种强大的IPC机制。它和网络套接字（TCP/UDP）编程接口类似（socket(),bind(),listen(),accept(),connect(),send(),recv()），但数据不走网络协议栈，而是在内核中直接拷贝，效率很高，且支持可靠的字节流（SOCK_STREAM）或不可靠的数据报（SOCK_DGRAM）模式，以及全双工通信。

选型考量：本地套接字功能全面，支持双向通信、多对一连接、可靠的传输，编程模型成熟。它的缺点是设置步骤比管道多，稍微重一些。在需要稳定的、双向的、可能演变为多进程服务的父子通信场景中，本地套接字是一个非常好的选择。它就像进程间的“TCP连接”，提供了更结构化和可靠的通信通道。

3. 实战：使用匿名管道实现一个任务分发与收集框架

理论说再多，不如一行代码。我们来实现一个经典的“Master-Worker”模型：父进程作为Master，负责生成一系列任务（比如计算数字的平方），然后通过管道分发给多个子进程（Worker）去执行，Worker将结果通过另一个管道传回给Master。我们将使用两个匿名管道来实现双向通信。

3.1 框架设计与管道建立

首先，我们需要建立两条通信链路：

任务管道：父进程写，子进程读。用于下发任务。
结果管道：子进程写，父进程读。用于回收结果。

由于我们要创建多个子进程，每个子进程都需要有自己的读/写端。如果只创建一对管道，所有子进程都会共享同一个读端，那么任务会被随机分发，无法控制。因此，更常见的做法是：为每个子进程单独创建一对管道。这样父进程可以精确地向指定子进程发送任务。

但为了示例清晰，我们先实现一个简化版：只创建一个子进程，使用两个管道。理解了核心，扩展到多个子进程只是管理数组的问题。

#include <iostream> #include <unistd.h> #include <sys/wait.h> #include <cstring> #include <vector> int main() { // 管道1: parent -> child (任务管道) int task_pipe[2]; // task_pipe[0]读, task_pipe[1]写 // 管道2: child -> parent (结果管道) int result_pipe[2]; // result_pipe[0]读, result_pipe[1]写 if (pipe(task_pipe) == -1 || pipe(result_pipe) == -1) { perror("pipe failed"); return 1; } pid_t pid = fork(); if (pid < 0) { perror("fork failed"); return 1; }

3.2 进程分工与描述符管理

接下来是关键一步：在fork()之后，父子进程要根据自己的角色，立即关闭不需要的文件描述符。这不仅是为了清晰，更是为了防止潜在的死锁。例如，如果结果管道的写端（result_pipe[1]）在父进程中没有被关闭，那么当子进程结束并关闭其写端后，父进程的read()在读完管道中所有数据后，会一直等待更多数据（因为从内核角度看，至少还有一个写端——父进程自己——未关闭），从而永远阻塞。

父进程代码块：

if (pid > 0) { // 父进程 // 父进程：向子进程发任务，不需要读任务管道，不需要写结果管道 close(task_pipe[0]); // 关闭任务管道的读端 close(result_pipe[1]); // 关闭结果管道的写端 // 准备一些任务数据，比如要计算的数字 std::vector<int> tasks = {1, 2, 3, 4, 5, 10, 20}; // 发送任务数量（让子进程知道要接收多少个） int task_count = tasks.size(); write(task_pipe[1], &task_count, sizeof(task_count)); // 发送所有任务数据 for (int num : tasks) { write(task_pipe[1], &num, sizeof(num)); std::cout << "[Parent] Sent task: " << num << std::endl; } // 任务发送完毕，关闭写端，告知子进程没有更多数据了 close(task_pipe[1]); // 现在，从结果管道读取子进程的计算结果 int result; while (read(result_pipe[0], &result, sizeof(result)) > 0) { std::cout << "[Parent] Received result: " << result << std::endl; } // 子进程已关闭结果管道写端，read返回0，循环结束 close(result_pipe[0]); // 关闭结果管道读端 // 等待子进程结束，回收资源 wait(nullptr); std::cout << "[Parent] All tasks processed. Exiting." << std::endl; }

子进程代码块：

else { // 子进程 (pid == 0) // 子进程：从父进程读任务，不需要写任务管道，不需要读结果管道 close(task_pipe[1]); // 关闭任务管道的写端 close(result_pipe[0]); // 关闭结果管道的读端 // 读取任务数量 int task_count; if (read(task_pipe[0], &task_count, sizeof(task_count)) <= 0) { std::cerr << "[Child] Failed to read task count." << std::endl; exit(1); } // 循环读取并处理每个任务 int num; for (int i = 0; i < task_count; ++i) { if (read(task_pipe[0], &num, sizeof(num)) <= 0) { std::cerr << "[Child] Failed to read task " << i << std::endl; break; } std::cout << "[Child] Received task: " << num << std::endl; // 执行“计算”任务（这里简单计算平方） int square = num * num; // 模拟一些处理时间 sleep(1); // 将结果写回给父进程 write(result_pipe[1], &square, sizeof(square)); std::cout << "[Child] Sent result: " << square << std::endl; } // 所有任务处理完毕，关闭管道端 close(task_pipe[0]); close(result_pipe[1]); // 关闭结果管道写端，这会向父进程发送EOF std::cout << "[Child] Finished processing. Exiting." << std::endl; exit(0); // 子进程退出 } return 0; }

这个例子清晰地展示了双向通信的流程：父进程先写后读，子进程先读后写。通过精心管理文件描述符的开闭，我们确保了数据流的正确方向和管道的正常终结。

实操心得：在编写管道通信代码时，养成“用完即关”的习惯。在fork()后，立刻在父进程和子进程中分别关闭自己用不到的那些描述符。这能有效避免文件描述符泄漏，更重要的是能确保read()在适当的时候返回0（读到EOF），而不是无限期阻塞。画一张描述符开闭的草图，是调试复杂管道程序的好方法。

4. 进阶：使用本地套接字实现一个全双工聊天程序

管道虽然高效，但毕竟是半双工，且对多个子进程的管理稍显复杂。当我们希望父子进程能像聊天一样随时互相发送消息时，本地套接字（AF_UNIX+SOCK_STREAM）是更优雅的选择。它建立后就是一个双向的字节流通道。

4.1 服务器端（父进程）实现

父进程将扮演服务器角色，创建套接字、绑定地址、监听并接受子进程的连接。

#include <iostream> #include <sys/socket.h> #include <sys/un.h> #include <unistd.h> #include <cstring> #include <string> #include <thread> // 为了演示，使用线程处理读写分离 void parent_process() { int server_fd; struct sockaddr_un addr; const char* socket_path = "/tmp/parent_child_chat.sock"; // 1. 创建本地流式套接字 if ((server_fd = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) { perror("socket error"); exit(EXIT_FAILURE); } // 2. 确保之前没有残留的socket文件 unlink(socket_path); // 3. 绑定地址 memset(&addr, 0, sizeof(addr)); addr.sun_family = AF_UNIX; strncpy(addr.sun_path, socket_path, sizeof(addr.sun_path) - 1); if (bind(server_fd, (struct sockaddr*)&addr, sizeof(addr)) == -1) { perror("bind error"); close(server_fd); exit(EXIT_FAILURE); } // 4. 监听连接 if (listen(server_fd, 5) == -1) { // 等待队列长度为5 perror("listen error"); close(server_fd); exit(EXIT_FAILURE); } std::cout << "[Parent] Server is listening on " << socket_path << std::endl; // 5. 接受子进程的连接 int client_fd; if ((client_fd = accept(server_fd, nullptr, nullptr)) == -1) { perror("accept error"); close(server_fd); exit(EXIT_FAILURE); } std::cout << "[Parent] Child process connected." << std::endl; // 关闭监听套接字，因为我们只需要一个连接 close(server_fd); unlink(socket_path); // 可以删除socket文件了 // 现在 client_fd 就是与子进程通信的全双工通道 // ... 读写逻辑将在后面与子进程一起展示 }

4.2 客户端（子进程）实现

子进程作为客户端，连接父进程创建的服务器。

void child_process() { int sock_fd; struct sockaddr_un addr; const char* socket_path = "/tmp/parent_child_chat.sock"; // 1. 创建套接字 if ((sock_fd = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) { perror("socket error"); exit(EXIT_FAILURE); } // 2. 设置地址并连接 memset(&addr, 0, sizeof(addr)); addr.sun_family = AF_UNIX; strncpy(addr.sun_path, socket_path, sizeof(addr.sun_path) - 1); // 需要稍等片刻，确保父进程服务器已经启动并开始监听 sleep(1); if (connect(sock_fd, (struct sockaddr*)&addr, sizeof(addr)) == -1) { perror("connect error"); close(sock_fd); exit(EXIT_FAILURE); } std::cout << "[Child] Connected to parent." << std::endl; // sock_fd 就是与父进程通信的全双工通道 // ... 读写逻辑 }

4.3 全双工读写与并发处理

现在，父子进程都获得了一个套接字描述符（父进程是client_fd，子进程是sock_fd）。这个描述符是可读可写的。为了实现真正的“聊天”，我们需要处理并发：既要能随时发送消息，也要能随时接收对方的消息。一个简单的方法是使用多线程：一个线程专门负责读，一个线程专门负责写。

以下是整合后的读写逻辑示例（使用C++11的std::thread）：

#include <thread> #include <atomic> std::atomic<bool> running{true}; // 读线程函数 void read_thread(int fd, const std::string& role) { char buffer[256]; ssize_t n; while (running) { n = read(fd, buffer, sizeof(buffer) - 1); if (n > 0) { buffer[n] = '\0'; std::cout << "[" << role << " Received] " << buffer << std::endl; } else if (n == 0) { std::cout << "[" << role << "] Connection closed by peer." << std::endl; running = false; break; } else { // n < 0 if (errno != EAGAIN && errno != EWOULDBLOCK) { // 忽略非阻塞下的暂时错误 perror("read error"); running = false; } // 简单起见，这里不做非阻塞IO处理，短暂休眠 std::this_thread::sleep_for(std::chrono::milliseconds(100)); } } } // 写线程函数 void write_thread(int fd, const std::string& role) { std::string input; while (running) { std::cout << "[" << role << " Input] > "; std::getline(std::cin, input); if (!running) break; if (input == "exit") { running = false; break; } input += '\n'; // 添加换行符作为消息分隔符（简单协议） if (write(fd, input.c_str(), input.length()) == -1) { perror("write error"); running = false; } } } // 在 parent_process 函数 accept 成功后，和 child_process 函数 connect 成功后调用 void start_chat(int fd, const std::string& role) { std::thread reader(read_thread, fd, role); std::thread writer(write_thread, fd, role); writer.join(); // 等待写线程结束（用户输入exit） running = false; // 通知读线程结束 reader.join(); close(fd); std::cout << "[" << role << "] Chat ended." << std::endl; }

在parent_process中，accept成功后调用start_chat(client_fd, "Parent")；在child_process中，connect成功后调用start_chat(sock_fd, "Child")。这样，父子进程就可以互相发送消息了。

注意事项：这个示例使用了简单的以换行符分隔消息的协议，并且read调用可能因为TCP流特性而读到不完整的行。生产环境需要更健壮的协议，例如在每个消息前加上长度字段。此外，多线程共享running标志和文件描述符，需要确保线程安全。这里使用std::atomic来保证running标志的可见性。对于更复杂的应用，可能需要使用更精细的同步机制。

5. 避坑指南：父子进程通信中的典型问题与排查

在实际开发中，光是跑通Demo远远不够，各种边界条件和异常情况才是真正的挑战。下面我总结了一些最常见的“坑”和排查思路。

5.1 管道读写阻塞与进程死锁

这是新手最容易遇到的问题。症状是程序“卡住”不动了。

场景还原：父进程创建管道后fork()出子进程。父进程想向子进程发送10个数字，然后读取子进程返回的10个结果。父进程的代码顺序是：write_all_tasks() -> close_write_end() -> read_all_results()。子进程的顺序是：read_all_tasks() -> process() -> write_all_results()。

问题：如果任务数据量很大，超过了管道的缓冲区大小（默认通常64KB），父进程的write_all_tasks()在写满缓冲区后就会阻塞，等待子进程来读取以腾出空间。但此时子进程还在执行read_all_tasks()，它可能因为某种原因（比如逻辑错误）没有开始读，或者读得很慢。这就形成了死锁：父进程等子进程读，子进程等父进程写（或者等别的）。如果父子进程都遵循“先读完所有任务，再开始处理并写结果”的模式，且任务数据量大，就极易发生。

解决方案：

非阻塞IO：使用fcntl()将管道设置为非阻塞模式（O_NONBLOCK）。这样write在缓冲区满时会立即返回-1并设置errno为EAGAIN，而不是阻塞。但这需要应用层实现重试或缓冲逻辑，复杂度高。
多线程/多进程：让读和写在不同的执行流中并发进行。例如，父进程可以用两个线程，一个线程专门负责向管道写任务，另一个线程专门负责从结果管道读结果。这样即使写任务阻塞，读结果的线程也能独立运行。
设计协议：不要一次性发送所有数据。采用“请求-响应”或“流式”处理。父进程发送一个任务，等待子进程返回一个结果，再发送下一个。这虽然降低了吞吐量，但逻辑简单，不易死锁。这就是上面“任务分发”示例采用的方法（先发数量，再循环收发）。
使用select/poll/epoll：这是处理多个I/O描述符的经典方案。父进程可以同时监控任务管道的写端和结果管道的读端，只在可写时才写任务，只在可读时才读结果。这能高效地管理多个阻塞点。

5.2 信号干扰与处理

信号是异步的，可能在任何时候打断你的程序流程。如果不妥善处理，会导致数据不一致或资源泄漏。

常见坑点：

在信号处理函数中调用不可重入函数：如printf、malloc、free等。这些函数内部可能使用全局数据结构或静态缓冲区，如果在主程序执行到一半时被信号打断并调用这些函数，可能导致死锁或数据损坏。在信号处理函数中，应只做最简单的操作，如设置一个全局的volatile sig_atomic_t标志位。
管道读写被信号中断：默认情况下，read和write等系统调用在阻塞时如果被信号处理函数打断，会返回-1并设置errno为EINTR。这是一个正常情况，不是错误！很多新手代码看到read返回-1就直接退出，导致程序意外终止。

正确做法：在循环中调用read/write，并检查errno。

ssize_t safe_read(int fd, void* buf, size_t count) { ssize_t n; do { n = read(fd, buf, count); } while (n == -1 && errno == EINTR); // 如果是被信号中断，则重试 return n; }

父子进程间的信号竞争：父进程在fork()后立即设置信号处理，但子进程可能在此之前就收到了信号。更安全的做法是，在fork()之前就屏蔽（block）相关信号，fork后在子进程中解除屏蔽并设置处理函数。

5.3 僵尸进程与资源回收

子进程结束后，如果父进程没有调用wait()或waitpid()来获取其退出状态，子进程就会变成“僵尸进程”（Zombie）。僵尸进程不占用内存，但会占用进程ID等系统资源。如果父进程长期不回收，系统中可用的进程ID可能会被耗尽。

解决方案：

同步等待：父进程在需要子进程结果的地方调用waitpid(pid, &status, 0)，这会阻塞直到指定子进程结束。

异步等待：父进程通过信号SIGCHLD来异步获知子进程结束。安装SIGCHLD信号处理函数，在其中调用waitpid(-1, &status, WNOHANG)来非阻塞地回收所有已结束的子进程。

void sigchld_handler(int sig) { (void)sig; // 防止未使用参数警告 int saved_errno = errno; // 保存errno，因为waitpid可能会修改它 while (waitpid(-1, nullptr, WNOHANG) > 0) { // 循环回收，直到没有僵尸子进程 } errno = saved_errno; } // 在主函数中设置 struct sigaction sa; sa.sa_handler = sigchld_handler; sigemptyset(&sa.sa_mask); sa.sa_flags = SA_RESTART | SA_NOCLDSTOP; // SA_RESTART使被中断的系统调用自动重启 sigaction(SIGCHLD, &sa, nullptr);

注意：信号处理函数中应使用while配合WNOHANG，因为同一时刻可能有多个子进程结束，但SIGCHLD信号可能只递交一次。

5.4 字节序与结构对齐问题

如果父子进程运行在同一台机器上，通常不存在字节序（大端/小端）问题。但是，如果你使用共享内存，并且将来可能扩展到不同架构的机器（虽然父子进程通常不会跨机器），或者你通信的数据结构中包含了int、short等类型，就需要考虑结构体对齐（Padding）问题。

问题：编译器为了性能，可能会在结构体的成员之间插入填充字节，使得结构体的大小不等于各成员大小之和。如果你直接将一个结构体memcpy到共享内存或管道中，另一个进程用同样的结构体类型去读，可能会因为两个进程编译时的对齐设置不同而导致错位。

解决方案：

使用序列化库：如Protocol Buffers、FlatBuffers、MessagePack等。这是最规范、最跨平台的方法。
手动序列化：如果数据简单，可以手动将结构体的每个基本类型成员转换为网络字节序（htonl,htons等）后再传输，接收方再转换回来。对于对齐问题，可以在定义结构体时使用编译器指令（如GCC的__attribute__((packed))）进行单字节对齐，但会牺牲一些性能。
传输纯字节流：避免直接传递结构体。设计一个简单的应用层协议，比如“类型+长度+数据”，将数据按字段逐个编码为字节流。

6. 性能优化与高级模式探讨

当基本的通信满足需求后，我们往往会追求更高的性能和更优雅的设计。这里分享几个进阶思路。

6.1 多子进程管理与负载均衡

在“Master-Worker”模型中，父进程（Master）需要管理多个子进程（Worker）。如何高效地给Worker派发任务并收集结果？

方案一：Round-Robin（轮询）父进程维护一个Worker管道写端的数组，每次有新任务，就按顺序发给下一个Worker。实现简单，但无法考虑Worker的负载差异。

方案二：任务队列+Worker竞争这是更常见的模式。父进程不直接决定任务给谁，而是维护一个任务队列。所有Worker通过某种机制（如共享内存中的锁、或者使用System V消息队列、POSIX消息队列）来竞争获取任务。这能实现自动的负载均衡。实现复杂度较高，需要处理进程间同步。

方案三：使用poll或epoll管理多个管道父进程需要同时读取所有子进程的结果管道。使用select在管道数量多时效率低（线性扫描）。poll稍好，而epoll是Linux上处理大量文件描述符的最高效接口。父进程将所有结果管道的读端添加到epoll实例中，然后在一个循环中等待事件。哪个管道有数据可读，就读取哪个，非常高效。

// 伪代码示例 int epoll_fd = epoll_create1(0); struct epoll_event ev, events[MAX_WORKERS]; for (每个Worker i) { ev.events = EPOLLIN; // 监听可读事件 ev.data.fd = result_pipe[i][0]; // 结果管道的读端 epoll_ctl(epoll_fd, EPOLL_CTL_ADD, ev.data.fd, &ev); } while (running) { int nfds = epoll_wait(epoll_fd, events, MAX_WORKERS, -1); for (int i = 0; i < nfds; ++i) { int ready_fd = events[i].data.fd; // 从 ready_fd 读取Worker i的结果 // ... } }