There are so many possible errors in POSIX environement. Why some of them (write to unconnected socket in particular) get special treatment in form of signals?
A:
David
2009-10-18 03:13:09
Socket is only an example. Question is general.
Łukasz Lew
2009-10-18 03:19:50
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
2009-10-18 03:28:15
(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
2009-10-18 03:29:38
A:
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.
EffoStaff Effo
2009-10-18 08:54:13
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.
EffoStaff Effo
2009-10-18 12:17:51
+2
A:
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
2009-11-05 23:31:31
A:
See this SO answer for a detailed explanation of why writing a closed descriptor / socket generates SIGPIPE.
Robert S. Barnes
2010-03-14 09:40:58