子线程阻塞于socket read时如何通过管道通知主线程及边界问题处理

TCP是面向字节流的传输协议，没有内置的报文边界，当前逻辑以read返回值小于缓冲区大小作为数据读取完成的判断依据，本身不符合流协议的特性，刚好读满1024字节的场景就是该逻辑缺陷的典型表现。

方案1：将socket设置为非阻塞模式，读完所有可用数据后再发通知 #

操作步骤：

• 提前调用fcntl(socket, F_SETFL, O_NONBLOCK)将socket设置为非阻塞模式
• 子线程调整为循环读取逻辑：
  • 若read返回值>0：将读取到的字节追加到全局缓冲区，继续下一轮读取
  • 若read返回值==0：对端已关闭连接，执行清理逻辑后退出循环
  • 若read返回值==-1且errno为EAGAIN/EWOULDBLOCK：当前内核socket缓冲区已无可用数据，退出循环
• 退出读取循环后统一调用write(pipe-write-file-descriptor, some-id, sizeof(int))通知主线程
  优点：无需修改上层通信协议，改造成本最低，完全规避刚好读满1024字节时的阻塞问题
  注意点：非阻塞模式下read返回-1时需要先判断errno，不要把正常的无数据可读场景当成错误处理

方案2：上层通信协议增加报文长度标识，按指定长度读取 #

操作步骤：

• 通信双方约定统一的报文结构，比如前4个字节为固定字节序（大端/小端）的整数值，标识本次报文的总字节长度
• 子线程先读取4字节的长度字段，换算出本次需要读取的总字节数
• 循环读取直到累计读取字节数达到约定的总长度，立即退出读取循环，调用管道通知主线程
  优点：从协议层面解决TCP流的边界问题，从根源上避免半包、粘包问题，可靠性最高，适合跨端生产通信场景
  注意点：需要确保通信两端都严格遵循相同的报文约定，长度字段的字节序必须统一

方案3：调整通知触发时机，每次追加数据后立即通知 #

操作步骤：

• 取消「读完所有数据再统一通知」的逻辑，每次read调用成功拿到数据、并完成全局缓冲区追加操作后，立刻调用管道写入通知主线程
• 主线程收到通知后自行判断全局缓冲区中的数据是否满足处理条件，不满足则继续等待下一次通知
  优点：逻辑改动最小，不需要修改socket属性或者通信协议，适合主线程支持分批处理数据的场景
  注意点：会增加主线程的唤醒次数，全局缓冲区的读写操作必须加互斥锁，避免多线程读写冲突

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