为何读取FIFO的进程卡在read()调用，而写入进程看似成功写入？

问题核心原因 #

你遇到的问题本质不是FIFO本身的特性限制，而是Python文件对象的用户态缓冲机制导致的：

• Python的open()函数默认使用全缓冲（缓冲区大小通常为4KB），当你保持FIFO写端句柄持续打开时，每次写入的7字节数据远小于缓冲阈值，会被滞留在Python的用户态缓冲区中，并未真正写入内核的FIFO管道。
• C端的read()调用会一直阻塞，因为内核FIFO中没有可用数据，直到有数据被刷入内核或者写端关闭（此时read()会返回0表示EOF）。
• 而每次循环执行open/close时，close()操作会强制将用户态缓冲区的内容刷入内核FIFO，C端就能立即读到数据，这就是临时方案有效的原因。

至于测试程序能正常运行，大概率是测试场景中触发了自动缓冲刷新（比如写入量刚好填满缓冲区、测试时手动触发了flush，或者测试代码用了无缓冲方式）。

你的疑问解答 #

1. 是否必须每次执行open/close系统调用？ #

不需要。这只是绕开缓冲问题的临时 workaround，并非FIFO的强制要求，频繁的open/close会带来额外的系统调用开销，反而降低效率。

2. 更高效的处理方式 #

有三种可靠的优化方案，按推荐优先级排序：

方案一：关闭Python层缓冲

打开FIFO时指定buffering=0（无缓冲），这样每次write()都会直接调用系统调用写入内核FIFO：

# 注意：无缓冲模式下必须用二进制写入
with open("caposc", "wb", buffering=0) as f:
    while True:
        f.write(b"abcdefg")  # 传递字节串

或者如果需要文本模式，每次写入后手动调用flush()强制刷入内核：

with open("caposc", "w") as f:
    while True:
        f.write("abcdefg")
        f.flush()  # 强制刷新用户态缓冲区到内核

方案二：直接使用系统调用（os模块）

Python的os.open()和os.write()是直接封装系统调用，跳过Python层的用户态缓冲，数据会直接写入内核FIFO：

import os

# 打开FIFO（只写模式，需确保FIFO已被读端创建或提前通过mkfifo创建）
fd = os.open("caposc", os.O_WRONLY)
try:
    while True:
        os.write(fd, b"abcdefg")  # 必须传递字节串
finally:
    os.close(fd)

方案三：匹配缓冲大小（不推荐）

将缓冲区大小设置为每次写入的字节数（7字节），这样每次写入都会填满缓冲区并自动刷入内核：

with open("caposc", "wb", buffering=7) as f:
    while True:
        f.write(b"abcdefg")

这种方式依赖Python的缓冲策略，可靠性不如前两种，不建议在生产环境使用。

补充FIFO核心特性（避免后续踩坑） #

• FIFO是字节流管道，读写没有固定的消息边界，需要自己处理数据的拆分/拼接。
• 读端打开FIFO时会阻塞，直到有写端打开；写端打开FIFO时也会阻塞，直到有读端打开（除非打开时指定O_NONBLOCK非阻塞模式）。
• 当所有写端关闭时，读端的read()会返回0（表示EOF）；当所有读端关闭时，写端的write()会触发SIGPIPE信号（默认导致进程退出）。

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