与 dup2()、exec() 和管道混淆

Question

我一直在努力理解涉及命令dup2()、exec() 和管道的概念。

我想要达到的目标：

将程序 X 的输出连接到程序 Y 的输入。

who | sort 之类的基本内容

有一个父级和 2 个子级，其中子级负责执行程序，而父级将程序传递给子级。

这是我对管道的不理解：

P1) 管道被视为文件，应该是单向的，但是是什么阻止我使用一个管道进行多个单向通信通道？ 所以，假设我有pipe1 和三个进程（P - 父级 - C1、C2、子级）通过分叉打开管道。所有这些进程都可以使用文件描述符。 假设我们一切正常，关闭未使用的管道末端，P 现在向C1 写入一些内容。 再次使用管道在C1 和C2 之间进行通信有什么问题？ 就在写这个问题的时候，我突然想到一个想法：谁读取它有问题，而许多进程可能同时打开它（两个进程阻塞读取），即系统无法确定谁想读取写入其中的缓冲数据？如果是这样，这是如何在系统中实现的？

我真的很想理解这个概念，所以请多多包涵。

为了将这个问题应用到现实生活中，我正在处理一些伪代码：

亲：

• P 关闭 pipe1 的不需要的读取端
• P 通过pipe1 将程序参数（'who'）发送到C1
• P关闭写端
• P 等待孩子退出

C1：

• C1 从pipe1 的读取端读取参数
• C1dup2()s 标准输出到pipe1 的写入端
• C1 关闭 pipe1 的两端（因为我们已经欺骗了它）
• C1execvp()s 程序（“谁”）

C2：

• C2 dup2()s 将 pipe1 的结尾读取到 stdin 以便它获取将要执行的程序的输入
• C2 关闭 pipe1 的两端
• C2 等待来自duped pipe1 的C1 的stdin 上的输入
• C2execvp()s 程序（'排序'）与此输入

---

现在，如果我按照上面描述的那样做，我就没有运气了。 但是，如果我引入另一个管道pipe2，它看起来像这样：

---

亲：

• P 关闭不需要的管道的两端 pipe2
• P 关闭 pipe1 的不需要的读取端
• P 通过pipe1 将程序参数（'who'）发送到C1
• P关闭写端
• P 等待孩子退出

C1：

• C1 关闭 pipe2 的读取结束
• C1 从pipe1 的读取端读取参数
• C1dup2()s 标准输出到pipe2 的写端
• C1 关闭 pipe2 的写结束
• C1 关闭了 pipe1 的两端——在这个孩子中 pipe2、pipe1 是多余的
• C1execvp()s 程序（'谁'）

C2：

• C2 dup2()s 读取 pipe2 的结尾到 stdin
• C2 关闭 pipe1 的两端
• C2 等待来自duped pipe2 的C1 的stdin 上的输入
• C2 使用此输入执行程序 sort

不应该在多个进程中重用管道的假设是否正确，因为系统可能不确定要“服务”谁？或者还有其他原因吗？

Answer 1

管道主要是为一对一的通信而设计的——一个作者，一个读者。虽然没有什么可以阻止您拥有尽可能多的阅读器和作者，但这种行为通常会使它不太有用，尤其是对于多个阅读器：

• 从管道读取是一种破坏性操作：通过管道发送的每个字节都将被恰好一个读取器读取，无论谁先抓取它。如果要广播某些信息，则需要使用不同的 IPC 机制或显式复制数据（如tee 命令）。
• 如果有多个写入者，他们的写入会以某种不可预测的方式穿插。唯一的保证是大小为PIPE_BUF 或更小的写入是原子的。
• 如果写入器的数量降至零，读取器会看到文件结束情况。

在您描述的架构中，您有两个独立的通信通道：P 将who 发送到 C1，C1 将运行 who 命令的输出发送到 C2。在 shell 脚本中，这将类似于

echo who | { read command; exec command; } | sort

echo who 在原始进程中而不是在子shell 中执行。

您的第一个建议不起作用，因为没有办法说 P 的输出将进入 C1，而 C1 的输出将进入 C2。它仍然是同一个管道，所以 P 的输出可以到 C2 并且 C1 的输出可以返回到它自己，或者它可以是混合的。