3

Possible Duplicate:
Why is writing a closed TCP socket worse than reading one?

Why doesn't an erroneous return value suffice?
What can I do in a signal handler that I can't do by testing the return value for EPIPE?

Community
  • 1
  • 1
Idan K
  • 20,443
  • 10
  • 63
  • 83
  • 1
    See http://stackoverflow.com/questions/2216374/why-is-writing-a-closed-tcp-socket-worse-than-reading-one (The accepted answer is a bit down, but explains the original purpose well. When you're explicittly dealing with TCP sockets it's common practice to set SIGPIPE to SIG_IGN and handle write/send returning -1) – nos Nov 09 '10 at 18:57

2 Answers2

1

Back in the old days almost every signal caused a Unix program to terminate. Because inter-process communication by pipes is fundamental in Unix, SIGPIPE was intended to terminate programs which didn't handle write(2)/read(2) errors.

Suppose you have two processes communicating through a pipe. If one of them dies, one of the ends of the pipe isn't active anymore. SIGPIPE is intended to kill the other process as well.

As an example, consider:

cat myfile | grep find_something

If cat is killed in the middle of reading the file, grep simply doesn't have what to do anymore and is killed by a SIGPIPE signal. If no signal was sent and grep didn't check the return value of read, grep would misbehave in some way.

Blagovest Buyukliev
  • 42,498
  • 14
  • 94
  • 130
0

As with many other things, my guess is that it was just a design choice someone made that eventually made it into the POSIX standards and has remained till date. That someone may have thought that trying to send data over a closed socket is a Bad Thing™ and that your program needs to be notified immediately, and since nobody ever checks error codes, what better way to notify you than to send a signal?

casablanca
  • 69,683
  • 7
  • 133
  • 150