为何Pipe通信中父进程wait不可省略？移除后子进程read异常

你遇到的问题核心在于父进程提前退出引发的连锁反应，并非pipe的read行为失效，具体拆解如下：

1. wait(0)的真实作用不只是"等待" #

原来的wait(0)除了让父进程等待子进程终止，更关键的是保证父进程在子进程之后退出，避免父进程先退出后导致子进程陷入异常状态。

2. 移除wait(0)后发生了什么？ #

当父进程写完ping、读完pong并打印后，会直接退出，此时会触发两个影响子进程的关键事件：

（1）前台进程组的SIGHUP信号 #

默认情况下，父进程是终端前台进程组的领头进程。父进程退出后，shell会立即接管前台进程组，并向原来进程组内的所有进程（包括子进程）发送SIGHUP信号。子进程默认会响应这个信号而终止——如果子进程刚写完pong，但"received ping"的输出还没完成缓冲区刷新，就会被直接杀死，导致你看不到这条打印。

（2）stdout行缓冲的坑 #

如果子进程用printf打印"received ping"时没有加换行符\n，也没手动调用fflush(stdout)，那么输出会暂存在用户空间的缓冲区里。子进程被SIGHUP终止时，内核不会自动刷新用户态缓冲区，这部分内容就直接丢失了。而父进程的"received pong"可能因为父进程退出时，内核自动刷新了stdout缓冲区，所以能正常显示。

3. 验证与修复方法 #

• 验证信号问题：在子进程开头加上signal(SIGHUP, SIG_IGN);忽略SIGHUP信号，再移除wait(0)运行，应该能看到"received ping"输出（前提是缓冲区问题也解决了）。
• 修复缓冲区问题：子进程的打印语句加上换行符，比如printf("received ping\n");，或者在打印后调用fflush(stdout);强制刷新。
• 规范Pipe使用：父子进程在完成读写后，及时关闭不需要的pipe文件描述符（比如父进程写完ping后关闭写端，子进程写完pong后关闭写端），避免read因为存在未关闭的写端而不必要阻塞。

内容的提问来源于stack exchange，提问作者Overstacked