Windows多线程TCP监听器：Abort()触发后recv/select无法立即返回求助

问题背景 #

在Windows平台开发基于C++的TCP Socket监听器，Listener()函数运行在独立线程中，负责接收探测器设备的图像帧。已实现Abort()函数，期望能在传输过程中（含无数据接收的空闲时段）安全中断Listener()线程。

当前问题 #

在探测器数据传输的空闲时段调用Abort()时，Listener()不会立即退出，而是卡在recv()/select()中等待探测器下一次发送数据，仅在收到数据后才会退出；但在探测器主动传输数据时调用Abort()则正常工作。

预期行为 #

触发Abort()时设置abortFlag为true并关闭ClientSocket，Listener()应立即检测到并退出，无论探测器是否在发送数据。

约束条件 #

无法通过软件触发探测器发送数据，其仅通过硬件触发发送数据块。

已尝试方案 #

• 为所有recv()循环添加带100ms超时的select()
• 将socket设置为非阻塞模式
• 在Abort()中显式调用shutdown(ClientSocket, SD_BOTH)
• 确认abortFlag设置和检查正常，且使用QT信号槽机制发送中止信号
• 尝试了QT网络框架，但问题依旧

核心疑问 #

1. 如何确保在探测器空闲时段调用Abort()时，recv()或select()/recv()组合能立即返回？
2. 是否存在shutdown()或closesocket()无法解除recv()/select()阻塞的边缘场景？
3. 是否应使用其他机制（如eventfd信号、虚拟管道/socketpair）？

解决方案 #

1. 排查线程同步与套接字操作有效性 #

Windows下，若阻塞中的recv()/select()对应的套接字被closesocket()关闭，理论上会立刻唤醒调用并返回错误码（如WSAENOTSOCK或WSAECONNABORTED）。你遇到的问题大概率是线程同步问题：

• 确保abortFlag是原子类型（比如std::atomic<bool>），避免线程缓存导致Listener()无法及时读取到flag的变化。
• 确认Abort()操作的是当前Listener()正在使用的ClientSocket：如果Listener()已经切换了套接字（比如重新接受了新连接），旧套接字的关闭操作自然无法影响当前的阻塞调用。
• 调整Abort()的操作顺序：先调用closesocket(ClientSocket)，再设置abortFlag = true，避免Listener()先读到flag但还没处理完阻塞调用。

2. 引入额外中断信号源（最可靠方案） #

既然套接字关闭无法按预期唤醒阻塞，最稳妥的方式是给Listener()线程添加一个独立的中断触发机制，与socket一起纳入select的检测范围：

• 使用Windows事件对象：
  1. 在Listener()线程初始化时，创建一个手动重置事件：HANDLE interruptEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
  2. 将该事件与ClientSocket一同加入select的检测集合（或用WSAEventSelect将套接字读事件与中断事件绑定）。
  3. 调用Abort()时，先设置abortFlag = true，再调用SetEvent(interruptEvent)，直接唤醒阻塞的select调用。
  4. Listener()从select返回后，优先检查abortFlag，若为true则立即退出线程。
• 使用虚拟套接字对（socketpair）：
  1. 创建一对相互连通的套接字（Windows下可通过WSASocket模拟实现）。
  2. Listener()将其中一端加入select的读集合。
  3. Abort()时向另一端发送一个字节的空数据，select会立刻检测到读事件并返回，此时Listener()检查abortFlag即可退出。

3. 优化select超时与非阻塞模式的使用 #

如果坚持使用select+超时的方案，需要优化逻辑：

• 不要依赖固定100ms超时，每次select循环开始前先检查abortFlag，若已触发则直接退出，无需进入阻塞等待。
• 非阻塞模式下，recv()会立即返回WSAEWOULDBLOCK，此时必须将中断信号源加入select集合，否则还是要等待超时才能检测到abortFlag。

关于shutdown/closesocket的边缘场景 #

确实存在少数边缘情况导致它们无法及时唤醒阻塞调用：

• 套接字已被其他线程提前关闭，Abort()中的closesocket()操作无效。
• TCP连接处于异常状态（如TIME_WAIT或CLOSE_WAIT），此时shutdown()可能无法立即触发recv()返回。
• 线程调度延迟：极端情况下，Listener()进入阻塞调用的瞬间，Abort()的关闭操作尚未完成，可能会短暂卡住，但不会一直等到探测器发数据才退出。

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