深度解析：多进程服务器中 accept() 被信号中断（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>

// 信号处理函数：回收子进程资源，防止僵尸进程
void recycle(int num) {

pid_t pid;
// 使用非阻塞 waitpid 循环回收所有已退出的子进程
while ((pid