FIFO命名管道读取时偶发返回0字节异常问题排查

这是POSIX FIFO（命名管道）的标准设计行为，不是内核或代码的偶发bug，核心是你对FIFO的工作模型存在认知偏差。
先明确FIFO阻塞模式下的核心规则：

• 读端调用open(O_RDONLY)会一直阻塞，直到存在至少一个写端持有FIFO的打开句柄才会返回
• 写端调用open(O_WRONLY)会一直阻塞，直到存在至少一个读端持有FIFO的打开句柄才会返回
• 当FIFO的所有写端句柄都被关闭时，阻塞在read()的读端会收到EOF，也就是read()返回0

你现在的代码采用每发一条消息就完整执行一次open/write/close流程的写法，完全踩中了FIFO流模型的竞态窗口：

• 你观察到的"写端关闭时读端open解除阻塞"本质是时序巧合：当读端处理完上一条256字节数据、关闭读句柄、进入下一轮循环阻塞在open()时，如果上一个写端还没执行到close()，等写端真正关闭句柄、下一个写端还没来得及打开的间隙，读端的open()可能因为FIFO状态变化提前返回，此时拿到的读句柄没有任何对应的写端，第一次read()就会直接返回0字节的EOF，这就是你看到的额外循环迭代的来源。
• 你觉得是"临时掩盖问题"的if (bytes_read > 0)判断，其实是所有POSIX字节流IO的标准处理逻辑——read()返回0是流结束的合法信号，不是异常错误，不存在"掩盖问题"的说法。

注意：FIFO是字节流，不是消息队列，本身不维护任何消息边界，即使你解决了开关句柄的竞态，也不能假设一次read()一定能读满256字节，这是流IO的基本特性。 #

不要在循环里反复open/close FIFO句柄，从根源上消除竞态来源，根据你的业务场景选下面任意一种方案即可。

方案1：长连接模式（推荐，性能最好） #

把open操作移到循环外，让读写两端在整个通信周期内保持FIFO句柄打开，完全避免反复开关带来的状态变化。
修正后的读端代码：

int main()
{
    int fd;
    const char *myfifo = "/tmp/channel";
    // mkfifo只需要执行一次，重复调用只会返回已存在的错误，无意义
    mkfifo(myfifo, 0666);

    // 全局只打开一次FIFO
    fd = open(myfifo, O_RDONLY);
    if (fd < 0) {
        perror("open fifo failed");
        return 1;
    }

    while (1)
    {
        char buf[256] = {0};
        int bytes_read = read(fd, buf, sizeof(buf));
        if (bytes_read == 0) {
            // 所有写端都已关闭，按需处理退出逻辑
            break;
        }
        if (bytes_read < 0) {
            perror("read fifo failed");
            break;
        }
        struct access_point *dev = (struct access_point *)buf;
        printf("Bytes read: %i\n", bytes_read);
        printf("ssid: %s\n", dev->ssid);
    }
    close(fd);
    unlink(myfifo); // 通信全部结束后再删除FIFO文件
    return 0;
}

对应的写端也只需要打开一次FIFO，循环写入256字节数据即可，不需要每次写都开关句柄。

方案2：短连接多写端模式（适配JS侧每次单独进程发消息的场景） #

如果你必须保持现在"每次发消息启动一次写进程、发完就退出"的短连接逻辑，只需要修改读端的open标志，用O_RDWR代替O_RDONLY即可：

fd = open(myfifo, O_RDWR);

这个写法的原理是：读端自己会持有一个FIFO的写端引用，内核会永远认为FIFO存在活跃写端，不会因为外部写端关闭就给读端返回EOF，从根源上消除短连接带来的0字节读取问题。 #

• 不要加sleep靠时序碰运气规避问题，只要竞态窗口存在，不管延时多久都有概率触发异常
• 如果后续需要传输变长数据，必须自己在应用层做拆包组包逻辑，不要依赖read()的返回长度判断消息边界
• 不需要每次打开FIFO都调用mkfifo，只需要在通信初始化时调用一次即可

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