 被信号中断（EINTR）的处理机制)
在开发高性能的多进程 TCP 服务器时，开发者经常会遇到一个棘手的现象：当客户端断开连接时，服务器端意外报错Interrupted system call，并导致逻辑进入异常分支。
本文将结合 Linux 系统编程理论与代码实践，深入探讨这一现象的成因及其标准解决方案。
1. 现象描述：消失的连接与“意外”的错误
在一个典型的多进程服务器模型中：
- 父进程：负责监听端口，阻塞在
accept()函数等待新连接。 - 子进程：当新连接到达时，父进程
fork()出一个子进程专门负责与该客户端通信。
问题触发点：
当一个客户端通信结束并主动关闭连接时，对应的子进程会退出。根据 Linux 机制，子进程退出会向父进程发送SIGCHLD信号。此时，如果父进程正阻塞在accept()调用上，这个信号会强制中断accept()的阻塞状态。
2. 核心原理：为什么会发生 EINTR？
在 Linux 中，某些“慢系统调用”（如accept()、read()、select()）在阻塞期间，如果被进程捕获的信号中断，系统调用会提前返回并报错。
- 返回值：
-1 - 错误码（errno）：
EINTR(定义在<errno.h>) - 后续行为：信号处理函数（Signal Handler）执行完毕后，原先被中断的系统调用默认不会自动恢复，而是直接报错返回。
3. 代码实战：复现并解决 EINTR 问题
下面的代码展示了如何正确注册信号捕捉函数、回收子进程资源，并处理accept的中断错误。
#include<stdio.h>#include<stdlib.h>#include<string.h>#include<unistd.h>#include<errno.h>#include<signal.h>#include<sys/wait.h>#include<arpa/inet.h>// 信号处理函数：回收子进程资源，防止僵尸进程voidrecycle(intnum){pid_tpid;// 使用非阻塞 waitpid 循环回收所有已退出的子进程while((pid
