ZMQ终止流程中pipe_term_ack被读取线程拦截的竞争条件疑问

前置背景 #

ZeroMQ的终止逻辑依赖内部pipe通信机制：当触发Socket终止（或全局zmq_term）时，会向目标Socket关联的pipe发送pipe_term信号，等待对端回复pipe_term_ack；reaper线程专门负责捕获这些pipe_term_ack，以此标记Socket资源可被安全释放。

异常拦截的时序过程 #

1. 读取线程处于阻塞状态：读取线程正卡在zmq_recv()调用上，该调用绑定的是它负责的Socket S，此时线程会持续监听Socket S关联的pipe上的所有流入消息。
2. 主线程触发终止：主线程调用zmq_term()（或单独终止Socket S），ZeroMQ内部向Socket S的pipe发送pipe_term信号，等待对端返回pipe_term_ack。
3. pipe_term_ack被错误拦截：当对端的pipe_term_ack消息发送过来时，由于读取线程正阻塞在该Socket的pipe监听上，会比reaper线程抢先捕获到这条消息。
4. 消息被丢弃：读取线程的逻辑只处理业务消息，无法识别pipe_term_ack是ZeroMQ内部的控制消息，会直接将其当作无效消息丢弃。
5. 阻塞与资源残留：reaper线程始终收不到对应Socket S的pipe_term_ack，会一直阻塞在资源清理流程中，导致zmq_term()无法完成，应用进程无法正常终止，对应的系统Socket资源也因未被正确释放而残留。

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