open() 打开 FIFO 会卡住是因为 POSIX 规定其默认阻塞式行为：O_RDONLY 需等待写端打开，O_WRONLY 需等待读端打开；解决方法是加 O_NONBLOCK 标志或协调两端启动顺序。
open() 打开 FIFO 时为什么会卡住？
Linux 下 mkfifo() 创建的命名管道默认是阻塞式打开的：open("myfifo", O_RDONLY) 会一直挂起，直到有另一个进程以 O_WRONLY 打开它；反过来，open("myfifo", O_WRONLY) 也会阻塞，直到有读端打开。这不是 bug，而是 POSIX FIFO 的设计行为。
常见错误现象：单侧启动程序后直接卡在 open()，strace 显示 openat(AT_FDCWD, "myfifo", O_RDONLY) 没有返回。
-
解决方法一（推荐）：用
O_NONBLOCK标志避免阻塞，但需自行处理EAGAIN/EWOULDBLOCK - 解决方法二：确保读写两端进程启动顺序合理，或用信号/临时文件协调启动时机
- 注意：
O_NONBLOCK对O_RDONLY和O_WRONLY行为不同——只读端加该标志后，即使没写端也能成功打开；只写端加该标志后，若无读端则open()直接失败并设errno = ENXIO
read() 和 write() 在 FIFO 上的阻塞逻辑
FIFO 的读写阻塞和普通文件完全不同：它依赖“两端是否就绪”。一旦写端关闭，读端 read() 会返回 0（表示 EOF）；如果读端提前关闭，写端 write() 会触发 SIGPIPE 或返回 -1 并设 errno = EPIPE。
关键细节：
立即学习“C++免费学习笔记（深入）”；
- 写入数据量 ≤ PIPE_BUF（通常 4096 字节）是原子的；超过则可能被拆包，且不保证顺序（多写端时尤其危险）
- 读端未打开时，带
O_NONBLOCK的open(O_WRONLY)失败；但只要读端曾经打开过、哪怕已关闭，open(O_WRONLY)仍可能成功（内核保留 FIFO 状态直到所有 fd 关闭） - 不要依赖
select()或poll()对 FIFO 做“可写”判断——它们对只写端的就绪判断不可靠，Linux 内核文档明确说明POLLOUT在 FIFO 上总是就绪（即使没读端），容易误判
一个安全的 C++ FIFO 读写封装示例
下面是一个最小可行的 RAII 封装，规避常见陷阱（如未检查 open() 返回值、忽略 ENXIO、不处理 SIGPIPE）：
#include#include #include #include #include class FifoWriter { int fd = -1; public: explicit FifoWriter(const char* path) { // 非阻塞打开，避免死等 fd = open(path, O_WRONLY | ONONBLOCK); if (fd == -1) { if (errno == ENXIO) { throw std::runtime_error("FifoWriter: no reader opened yet"); } throw std::runtime_error(std::string("open failed: ") + strerror(errno)); } // 忽略 SIGPIPE，让 write 返回 EPIPE 而非崩溃 signal(SIGPIPE, SIG_IGN); }
~FifoWriter() { if (fd_ != -1) close(fd_); } ssize_t write(const void* buf, size_t len) { return ::write(fd_, buf, len); }};
// 读端类似，但 open(O_RDONLY | O_NONBLOCK) 总是成功，无需 ENXIO 检查
为什么 unlink() 后还能读写？FIFO 的生命周期真相
unlink("myfifo")只删除目录项，不影响已打开的 fd。只要至少一个进程还持有该 FIFO 的读或写 fd，内核就会维持其存在。这和普通文件一致，但容易被误解为“删了就没了”。实战中要注意：
- 服务进程重启前应先
unlink()旧 FIFO，否则mkfifo()会失败（errno = EEXIST）- 不要在读写过程中反复
unlink()+mkfifo()—— 正在使用的 FIFO 不会被真正销毁，但新创建的同名 FIFO 是另一个 inode，老进程继续读写旧的，新进程拿到新的，导致通信错乱- 调试时用
lsof | grep myfifo查看哪些进程还在占用 FIFO，比单纯看文件是否存在更可靠FIFO 的复杂点不在语法，而在状态协同：它强制要求你思考“谁先启动”“谁先关闭”“错误如何传播”。漏掉任意一环，程序就可能静默卡死或崩溃。
