SIGPIPE 为什么存在？

Because your program may be waiting for I/O or otherwise suspended. A SIGPIPE interrupts your program asynchronously, terminating the system call, and so can be handled immediately.

Update

Consider a pipeline A | B | C.

Just for definiteness, we'll assume that B is the canonical copy loop:

while((sz = read(STDIN,bufr,BUFSIZE))>=0)
write(STDOUT,bufr,sz);

B is blocked on the read(2) call waiting for data from A when C terminates. If you wait for the return code from write(2), when will B see it? The answer, of course, is not until A writes more data (which could be a long wait -- what if A is blocked by something else?). Notice, by the way, that this also allows us a simpler, cleaner program. If you depended on the error code from write, you'd need something like:

while((sz = read(STDIN,bufr,BUFSIZE))>=0)
if(write(STDOUT,bufr,sz)<0)
break;

Another update

Aha, you're confused about the behavior of the write. You see, when the file descriptor with the pending write is closed, the SIGPIPE happens right then. While the write will return -1 eventually, the whole point of the signal is to notify you asynchronously that the write is no longer possible. This is part of what makes the whole elegant co-routine structure of pipes work in UNIX.

Now, I could point you to a whole discussion in any of several UNIX system programming books, but there's a better answer: you can verify this yourself. Write a simple B program[1] -- you've got the guts already, all you need is a main and some includes -- and add a signal handler for SIGPIPE. Run a pipeline like

cat | B | more

and in another terminal window, attach a debugger to B and put a breakpoint inside the B signal handler.

Now, kill the more and B should break in your signal handler. examine the stack. You'll find that the read is still pending. let the signal handler proceed and return, and look at the result returned by write -- which will then be -1.

[1] Naturally, you'll write your B program in C. :-)

I think it is to get the error handling correct without requiring a lot of code in everything writing to a pipe.

Some programs ignore the return value of write(); without SIGPIPE they would uselessly generate all output.

Programs that check the return value of write() likely print an error message if it fails; this is inappropriate for a broken pipe as it is not really an error for the whole pipeline.

I don't buy the previously-accepted answer. SIGPIPE is generated exactly when the write fails with EPIPE, not beforehand - in fact one safe way to avoid SIGPIPE without changing global signal dispositions is to temporarily mask it with pthread_sigmask, perform the write, then perform sigtimedwait (with zero timeout) to consume any pending SIGPIPE signal (which is sent to the calling thread, not the process) before unmasking it again.

I believe the reason SIGPIPE exists is much simpler: establishing sane default behavior for pure "filter" programs that continuously read input, transform it somehow, and write output. Without SIGPIPE, unless these programs explicitly handle write errors and immediately exit (which might not be the desired behavior for all write errors, anyway), they will continue running until they run out of input even if their output pipe has been closed. Sure you can duplicate the behavior of SIGPIPE by explicitly checking for EPIPE and exiting, but the whole purpose of SIGPIPE was to achieve this behavior by default when the programmer is lazy.

https://www.gnu.org/software/libc/manual/html_mono/libc.html

This link says:

A pipe or FIFO has to be open at both ends simultaneously. If you read from a pipe or FIFO file that doesn't have any processes writing to it (perhaps because they have all closed the file, or exited), the read returns end-of-file. Writing to a pipe or FIFO that doesn't have a reading process is treated as an error condition; it generates a SIGPIPE signal, and fails with error code EPIPE if the signal is handled or blocked.

— Macro: int SIGPIPE

Broken pipe. If you use pipes or FIFOs, you have to design your application so that one process opens the pipe for reading before another starts writing. If the reading process never starts, or terminates unexpectedly, writing to the pipe or FIFO raises a SIGPIPE signal. If SIGPIPE is blocked, handled or ignored, the offending call fails with EPIPE instead.

Pipes and FIFO special files are discussed in more detail in Pipes and FIFOs.

Machine info:

Linux 3.2.0-53-generic #81-Ubuntu SMP Thu Aug 22 21:01:03 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

I wrote this code below:

// Writes characters to stdout in an infinite loop, also counts
// the number of characters generated and prints them in sighandler
// writestdout.c


# include <unistd.h>
# include <stdio.h>
# include <signal.h>
# include <string.h>


int writeCount = 0;
void sighandler(int sig) {
char buf1[30] ;
sprintf(buf1,"signal %d writeCount %d\n", sig, writeCount);
ssize_t leng = strlen(buf1);
write(2, buf1, leng);
_exit(1);


}


int main() {


int i = 0;
char buf[2] = "a";


struct sigaction ss;
ss.sa_handler = sighandler;


sigaction(13, &ss, NULL);


while(1) {


/* if (writeCount == 4) {


write(2, "4th char\n", 10);


} */


ssize_t c = write(1, buf, 1);
writeCount++;


}


}

// Reads only 3 characters from stdin and exits
// readstdin.c


# include <unistd.h>
# include <stdio.h>


int main() {


ssize_t n ;
char a[5];
n = read(0, a, 3);
printf("read %zd bytes\n", n);
return(0);


}

Output:

$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 11486


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 429


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 281


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 490


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 433


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 318


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 468


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 11866


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 496


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 284


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 271


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 416


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 11268


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 427


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 8812


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 394


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 10937


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 10931


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 3554


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 499


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 283


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 11133


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 451


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 493


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 233


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 11397


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 492


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 547


$ ./writestdout | ./readstdin
read 3 bytes
signal 13 writeCount 441

You can see that in every instance SIGPIPE is only received after more than 3 characters are (tried to be) written by the writing process.

Does this not prove that SIGPIPE is not generated immediately after reading process terminates but after an attempt to write some more data to a closed pipe?