6
|
Here are some options I thought of, not sure which is the right one. a) There was an I/O error reading from the pipe. b) The process writing to the other end of the pipe died with a failure. c) All processes who could write to the pipe have closed it. d) The write buffer of the pipe is full. e) The peer has closed the other direction of the duplex pipe. f) Writing failed because there are no processes which could read from the pipe. g) A system call returned the EPIPE error, and there was no error handler installed. |
||||||||
|
11
|
A process receives a SIGPIPE when it attempts to write to a pipe (named or not) or socket of type SOCK_STREAM that has no reader left. It's generally wanted behaviour. A typical example is:
You don't want The
Will write "y" until some-command terminates. Note that it's not only when commands exit, it's when all the reader have closed their reading fd to the pipe. In:
Their will be 1 (the subshell), then 2 (subshell + sleep), then 1 (subshell) then 0 fd reading from the pipe after the subshell explicitely closes its stdin, and that's when Above, most shells use a When a process ignores the SIGPIPE, the writing system call (generally |
||
5
|
(f)
Although unless you duplicate descriptors and fork, there can only be one process to start with: generally a pipe has one reader and one writer, and when one of them closes the connection, the pipe is defunct. If you are using a named pipe, you can can make multiple connections (in serial) with it, but each one represents a new pipe in this sense. So a "pipe" to a thread or process is synonymous with a file descriptor. From
So a "broken pipe" is to the writer what EOF is to the reader. |
||||
|
0
|
A broken pipe happens when the reading process exits before the writing process. So I would go with (f) |
||||
|