Linux中的Pipe和FIFO的原理浅析

以前从编程角度写过Linux的Pipe和FIFO，主要侧重于使用，附带了简单的原理介绍。（连接以下）

http://my.oschina.net/u/158589/blog/54705

http://my.oschina.net/u/158589/blog/55051

今天在看Understanding The Linux Kernel时，发现本身对Pipe和FIFO的理解稍显不足，这里简单的对其原理作一些补充。主要采用Question & Answer的形式。

1. 为何要将FIFO和Pipe放在一块儿讲？他们间的区别是什么？

缘由是他们的核心数据结构是同样的，pipe_inode_info，而且，FIFO的读写函数和pipe的读写函数也一致。

关于区别，如下要稍微讲一下。使用上的区别参见本文开头的两篇博文。

核心区别有两点。

第一，fifo出如今系统目录树中，而pipe则在特殊文件系统pipefs中。

第二，fifo是双向通讯管道，而pipe是单向的。

 

2. Pipe和FIFO有对应的disk image吗？有对应的indoe吗？他们属于同一个文件系统吗？

pipe和fifo都没有对应的disk image。

他们都是文件，因此确定有inode。同时，当建立一个pipe或者fifo时，其实是建立了一个inode和两个file object.

pipe属于pipefs文件系统，fifo不是。因此他们不属于同一个文件系统。

值得注意的是如下两点：

第一， pipefs这个特殊的文件系统在VFS的目录中是没有的，用户不可见，它是在kernel初始化时进行建立而且挂载到VFS上的。

第二，虽然fifo在VFS的目录树下，可是它并不对应disk上的文件，有点像device文件。其核心的buffer是kernel中的buffer.

 

 

3. ls | more背后发生了什么？

step1: shell建立一个pipe（假设其file descriptor是3和4，这样方便讨论）。

step2: shell fork出两个子进程。此时，这两个子进程同继承了父进程的文件描述符，也就是说，他们一样有3和4.

step3: 第一个子进程调用dup2(4, 1)。这就将1（标准输出）的file object关闭了，而且，1这个文件描述符，此时指向了4文件描述符指向的file object，即pipe的写端。子进程关闭3和4。子进程execve(), 执行ls命令。因为execve也是用的同一个文件描述符表，因此此时ls的输出其实是pipe的写端。

step4: 第二个子进程调用dup2(3, 0)。如上，0（标准输入）的file object关闭，而且，0这个文件描述符，指向了3这个文件描述符指向的file object，即pipe的读端。子进程关闭3和4. 子进程execve(), 执行more命令。此时，more的输入其实是pipe的读端。

因而，ls的输出就顺利的重定向到more的输入了。

 

4. Pipe和FIFO使用的多吗？

Pipe就不用说了，shell中常常用到，实际编程中若是遇到重定向或者父子进程通讯，pipe也是一个不错的选择。就我目前看到过的代码而言，shell中pipe使用较多，c中pipe也有用到，但明显没有semaphore，socket等广泛。

FIFO的话，说实话，基本没见过。我认为缘由是他能作的，socket也必定能作，而且能作的更好。因此FIFO就有点累赘了。另外，从本文开头的两篇连接中，咱们能够看到，FIFO的编程有点麻烦，要对读写进行比较精确的控制，防止死锁或者竞争。

就到这里吧。