Linux下基于文件读写的pipe()替代实现是否合法？

先看一下你给出的实现代码：

int pipe(int pipefd[2]) { 
    char *name = unique_name(); 
    pipefd[1] = open(name, O_WRONLY|O_CREAT|O_TRUNC, 0600); 
    pipefd[0] = open(name, O_RDONLY, 0600); 
    unlink(name); 
    return 0; 
}

很明确地说，这个实现不能作为标准pipe()的合法替代方案，它和标准管道的核心语义、行为存在多处根本性差异，具体问题如下：

• 原子性与竞争风险：标准pipe()是内核原子性地创建管道的读写两端，完全依赖内核机制避免命名冲突。而你的实现依赖unique_name()生成临时文件名，即便这个函数能生成看似唯一的名字，在unique_name()返回后到open()创建文件的窗口中，仍然存在其他进程创建同名文件的竞争可能——这会导致open()返回错误，或者意外打开了其他进程的文件，完全违背了管道的私有性。就算给open()加上O_EXCL标志避免这个问题，也无法达到标准管道那种无命名、完全内核级的原子性。

• 信号与错误语义不匹配：标准管道有一个关键行为：当读端所有文件描述符被关闭后，写端执行写操作会收到SIGPIPE信号，同时系统调用返回EPIPE错误。但你的临时文件实现完全没有这个逻辑——就算读端关闭，写端写临时文件依然会成功（直到磁盘空间耗尽），这会导致依赖这个信号的程序彻底失效。

• 阻塞行为与缓冲机制差异：标准管道是基于内核内存的环形缓冲，写操作在缓冲区满时会阻塞，读操作在缓冲区空时会阻塞（除非设置了非阻塞模式）。而临时文件是基于文件系统（哪怕是tmpfs）的存储，写操作只要有磁盘/内存空间就不会阻塞，读操作在没有数据时不会阻塞，而是直接返回0（EOF）——这完全不符合管道的同步语义，依赖管道阻塞特性的进程间通信逻辑会彻底混乱。

• 文件类型与属性不一致：标准管道对应的是FIFO特殊文件（S_IFIFO），而临时文件是普通文件（S_IFREG）。很多程序会通过fstat()检查文件类型来判断是否是管道，进而调整行为——你的实现会让这类程序误判，引发异常。另外，标准管道不支持lseek()操作，而临时文件可以，这也是一个隐性的行为差异。

• 错误处理完全缺失：标准pipe()在创建失败时会返回-1，并设置对应的errno（比如EMFILE表示文件描述符耗尽、ENFILE表示系统文件表满）。但你的实现完全没有检查unique_name()、open()的返回值，哪怕这些调用失败，依然会返回0，调用者无法感知错误，这严重违背了标准函数的错误处理约定。

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