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）：
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
#include <fcntl.h>
#include <sys/stat.h>
#include <unistd.h>
#include <cerrno>
#include <stdexcept>
<p>class FifoWriter {
int fd<em> = -1;
public:
explicit FifoWriter(const char* path) {
// 非阻塞打开，避免死等
fd</em> = open(path, O_WRONLY | O<em>NONBLOCK);
if (fd</em> == -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);
}</p><pre class='brush:php;toolbar:false;'>~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 的复杂点不在语法，而在状态协同：它强制要求你思考“谁先启动”“谁先关闭”“错误如何传播”。漏掉任意一环，程序就可能静默卡死或崩溃。
