为什么“yes | sleep 10”管道不会失败

Question

在考虑如何在我自己的一个程序中实现某个功能时，我一直想知道 bash 如何在内部处理以下性质的管道：

yes | sleep 10

这显然没有任何作用，但我不明白这不会导致错误。我会认为要么：

• 因为sleep 不从标准输入读取，连接两个进程的管道会填满并导致yes 在尝试写入现在已满的管道时无限期阻塞

• 如果使用非阻塞 IO，如果首先执行 yes 并在 sleep 进程甚至运行之前写入管道并且因此没有进程连接到管道

我想这是我的一些重大误解。我试过查看 bash 源代码，但那已经超出了我的想象。

Answer 1

这是运行 shell 命令yes | sleep 10 时实际发生的情况。

首先，shell 使用pipe system call 创建一个anonymous pipe。 pipe 系统调用打开两个文件描述符，即管道的读取端和写入端。写入到写入端的任何内容都可以从读取端读取。

此后，shell 使用fork system call 创建两个子进程。两个孩子并行运行。

• 在一个孩子中，shell 将管道的写入端连接到标准输出并关闭读取端。然后shell调用execve system call，用yes的代码镜像替换本进程中的代码镜像。
  程序yes 尽可能长时间地写入管道。如果在管道的读取端没有活动的read 调用，write 调用只会阻塞。 （实际上有一个小的缓冲区，write 在阻塞之前会填满，但这在这里无关紧要。）
• 在另一个孩子中，shell 将管道的读取端连接到标准输入并关闭写入端。然后shell调用execve系统调用将本进程中的代码镜像替换为sleep的代码镜像。 程序sleep 10 秒内什么都不做。
• 原始 shell 进程关闭管道的两端并等待其两个子进程退出（使用 wait system call）。

一旦 10 秒结束，运行 sleep 的进程就会退出。此时，管道的读取端不再在任何进程中打开。当一个进程试图写入一个读端未在任何进程中打开的管道时，内核会向写入进程发送一个SIGPIPE 信号。因此，运行yes 的进程被 SIGPIPE 信号杀死。

此时，shell 检测到其管道两端的子进程都已退出。管道命令返回右边的状态，即0（sleep退出成功）。

因为 sleep 不从标准输入读取，连接两个进程的管道会填满，并导致 yes 在尝试写入现在已满的管道时无限期阻塞

这是正确的。

如果使用非阻塞IO，如果先执行yes并在睡眠进程运行之前写入管道，则应该会发生错误，因此没有进程连接到管道的读取端

这在几个地方是不正确的。 yes 不使用非阻塞 IO。它与sleep 并行执行，而不是首先执行。永远不会有任何时间点没有进程连接到管道的读取端，直到sleep 退出。根据时间的不同，yes 可能会在sleep 开始执行之前开始写入，甚至可能在sleep 程序的子进程被分叉之前，但是当pipe 调用返回时读取端变为打开状态，在写端打开的同时。