Linux下C语言套接字基于事件通信时如何通知客户端终止处理

核心矛盾是阻塞IO模式下双端均卡在等待对方传输数据的系统调用中，没有预留控制信令的收发逻辑，可按以下步骤改造：

1. 改造IO模型避免单调用阻塞 #

服务端侧 #

将原单线程阻塞recv()的逻辑替换为poll()/epoll() IO多路复用，同时监听三类事件：

• 套接字读事件：用于接收客户端返回的业务处理结果
• 套接字写事件：用于触发停止指令的下发
• 自定义特定事件：即你需要捕获的停止触发事件
  当特定事件触发时，无需等待recv()返回，直接向套接字写入停止控制帧即可。

客户端侧 #

不要阻塞在system()调用上等待子进程返回，改为fork() + exec()的方式启动处理子进程并记录子进程PID，同样用poll()监听三类事件：

• 子进程退出事件：可通过signalfd()将SIGCHLD信号转为文件描述符事件监听
• 套接字读事件：用于接收服务端下发的停止指令
• 套接字写事件：子进程正常退出后用于回传处理结果

2. 定义结构化通信帧区分控制信令与业务数据 #

在原有裸数据传输的基础上增加简单帧头，避免控制信令和业务数据混淆，参考定义：

#define FRAME_TYPE_BUSINESS_RES 1  // 业务处理结果帧
#define FRAME_TYPE_STOP_REQ 2      // 停止任务指令帧
#define FRAME_TYPE_STOP_ACK 3      // 停止任务响应帧

typedef struct {
    uint32_t total_len;  // 整帧长度（含帧头）
    uint8_t type;        // 帧类型
    uint8_t payload[];   // 可变长负载
} comm_frame_t;

服务端触发停止逻辑时，直接写入type = FRAME_TYPE_STOP_REQ的空负载帧即可。

3. 客户端停止逻辑实现 #

客户端监听到套接字读事件后，优先读取帧头判断类型：

• 如果是业务类帧走原有处理逻辑
• 如果是停止指令帧，直接调用kill()向记录的子进程PID发送SIGTERM信号终止处理任务，之后回传FRAME_TYPE_STOP_ACK帧给服务端，双端即可回归正常的通信角色。

低成本临时改造方案 #

如果暂时不想重构IO模型，可通过信号打断阻塞调用实现：

• 服务端为阻塞在recv()的线程注册SIGUSR1信号处理函数，特定事件触发时向该线程发SIGUSR1，recv()会被打断返回EINTR错误，此时即可下发停止指令，之后重新进入recv()等待响应。
• 客户端单独启动一个线程阻塞在套接字recv()上，收到停止指令后向主线程发信号打断system()调用，再终止处理子进程即可。该方案改造成本低但容易出现信号竞态问题，仅适合临时使用。

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