与dup2（），exec（）和管道混淆

Question

I have been struggling to understand the concept involving the commands dup2() , exec() and pipes in conjunction.

The thing I am trying to achieve:

Pipe the output of a program X to the input of a program Y.

Something basic like who | sort who | sort

with a parent and 2 children, where the children are responsible for executing the programs and the parent passing the programs to the children.

Here is what I don't understand about pipes:

P1) Pipes are treated like files and should be unidirectional, but what prevents me from using one pipe for multiple unidirectional communication channels ? So, let's say I have pipe1 and three processes ( P - parent - C1 , C2 , children) that have the pipe open by forking. All of these processes get to use the file descriptors. Let's assume we are doing everything correctly, closing the unused pipe ends, P now writes something to C1 . What is the issue with using the pipe for communication between C1 and C2 again? Just while writing this question, an idea hit me: Is there an issue with who reads from it while many processes may have it open simultaneously (two processes are blocking to get a read), ie the system cannot say for sure who wants to read the buffered data written into it? If so, how is this implemented in the system ?

I really try to understand the concept, so please bear with me.

To apply this question into real life here is some pseudocode I am dealing with:

P:

• P closes unneeded read end of pipe1
• P sends program argument ('who') to C1 via pipe1
• P closes write end
• P waits for children to exit

C1:

• C1 reads the argument from the read end of pipe1
• C1 dup2() s the standard out to the write end of pipe1
• C1 closes both ends of pipe1 (because we duped it already)
• C1 execvp() s the program ('who')

C2:

• C2 dup2() s read end of pipe1 to stdin so that it gets input for the program that will be executed
• C2 closes both ends of pipe1
• C2 waits for input on stdin of C1 from the dup ed pipe1
• C2 execvp() s program ('sort') with this input

---

Now, if I were to do it as described above, I would have no luck. However if I introduced another pipe pipe2 it looks something like this:

---

P:

• P closes both ends of unneeded pipe pipe2
• P closes unneeded read end of pipe1
• P sends program argument ('who') to C1 via pipe1
• P closes write end
• P waits for children to exit

C1:

• C1 closes read end of pipe2
• C1 reads the argument from the read end of pipe1
• C1 dup2() s the standard out to the write end of pipe2
• C1 closes write end of pipe2
• C1 closes both ends of pipe1 -- with pipe2 , pipe1 redundant in this child
• C1 execvp() s the program ('who')

C2:

• C2 dup2() s read end of pipe2 to stdin
• C2 closes both ends of pipe1
• C2 waits for input on stdin of C1 from the dup ed pipe2
• C2 executes program sort with this input

Is the assumption correct that pipes should not be reused in multiple processes because the system may not be sure whom to "serve" ? Or is there any other reason for this ?

Answer 1

Pipes are primarily designed for one-to-one communication — one writer, one reader. While there is nothing that prevents having as many readers and writers as you want, the behavior often makes this not very usable, especially with multiple readers:

• Reading from a pipe is a destructive operation: each byte sent through the pipe will be read by exactly one of the readers, whoever grabs it first. If you want to broadcast some information, you need to either use a different IPC mechanism or explicitly replicate the data (like the tee command).
• If there are multiple writers, their writes are interspersed in a somewhat unpredictable way. The only guarantee is that writes of size PIPE_BUF or less are atomic.
• If the number of writers drops to zero, the reader sees an end-of-file condition.

In the architecture you're describing, you have two independent communication channels: P sends who to C1, and C1 sends the output of running the who command to C2. In a shell script, that would be something similar to

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

with echo who executed in the original process rather than in a subshell.

Your first proposal doesn't work because there's no way to say that the output of P will go to C1 and the output of C1 will go to C2. It's still the same pipe, so the output of P could go to C2 and the output of C1 could go back to itself, or it could be a mixture.