3

There are so many possible errors in the POSIX environment. Why do some of them (like writing to an unconnected socket in particular) get special treatment in the form of signals?

Nick Caplinger
  • 784
  • 6
  • 10
Łukasz Lew
  • 48,526
  • 41
  • 139
  • 208

4 Answers4

4

This is by design, so that simple programs producing text (e.g. find, grep, cat) used in a pipeline would die when their consumer dies. That is, if you're running a chain like find | grep | sed | head, head will exit as soon as it reads enough lines. That will kill sed with SIGPIPE, which will kill grep with SIGPIPE, which will kill find with SEGPIPE. If there were no SIGPIPE, naively written programs would continue running and producing content that nobody needs.

If you don't want to get SIGPIPE in your program, just ignore it with a call to signal(). After that, syscalls like write() that hit a broken pipe will return with errno=EPIPE instead.

Alexey Feldgendler
  • 1,792
  • 9
  • 17
1

See this SO answer for a detailed explanation of why writing a closed descriptor / socket generates SIGPIPE.

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

Community
  • 1
  • 1
Robert S. Barnes
  • 39,711
  • 30
  • 131
  • 179
0

SIGPIPE isn't specific to sockets — as the name would suggest, it is also sent when you try to write to a pipe (anonymous or named) as well. I guess the reason for having separate error-handling behaviour is that broken pipes shouldn't always be treated as an error (whereas, for example, trying to write to a file that doesn't exist should always be treated as an error).

Consider the program less. This program reads input from stdin (unless a filename is specified) and only shows part of it at a time. If the user scrolls down, it will try to read more input from stdin, and display that. Since it doesn't read all the input at once, the pipe will be broken if the user quits (e.g. by pressing q) before the input has all been read. This isn't really a problem, though, so the program that's writing down the pipe should handle it gracefully.

David
  • 2,821
  • 20
  • 16
  • Socket is only an example. Question is general. – Łukasz Lew Oct 18 '09 at 03:19
  • In that case, what kind of signals are you interested in? Many of them are sent *asynchronously* (i.e. not in response to any particular operation requested by the program), or they're in response to a hardware exception (such as `SIGFPE` or `SIGSEGV`) rather than a system call — whereas `SIGPIPE` **is** sent in response to a system call (`write()`). – David Oct 18 '09 at 03:28
  • (P.S. Apologies for the stray HTML-entity in the above comment. It should have been a dash, but SO seems to have interpreted it literally.) – David Oct 18 '09 at 03:29
0

it's up to the design.

at the beginning people use signal to control events notification which were sent to the user space, and later it is not necessary because there're more popular skeletons such as polling which don't require a system caller to make a signal handler.

Test
  • 1,697
  • 1
  • 11
  • 10
  • Can you give some reference to this? – Łukasz Lew Oct 18 '09 at 11:02
  • traditional siginal can only process per FD notification, and signals are NOT an event driven framework - it is easy to get carried away and try turning the signals system into an event-driven driver for a program, but signal handling functions were not meant for that. so there're only some per FD functionality related SIGXXXs and system behaviors were defined. please google "per FD RT signal posix select poll AIO" to learn the details. – Test Oct 18 '09 at 12:17