|
Is there any advantage to handling the signal, rather than just ignoring it and checking for the EPIPE error? Are there any useful parameters passed to the signal catching function?
Unix Socket FAQ for Network programming
(Continued from previous question...)
Is there any
advantage to handling the signal, rather than just ignoring it and
checking for the EPIPE error? Are there any useful parameters passed
to the signal catching function?
See that send()/write() can generate SIGPIPE. Is there any
advantage to handling the signal, rather than just ignoring it and
checking for the EPIPE error? Are there any useful parameters passed
to the signal catching function?
In general, the only parameter passed to a signal handler is the
signal number that caused it to be invoked. Some systems have
optional additional parameters, but they are no use to you in this
case.
My advice is to just ignore SIGPIPE as you suggest. That's what I do
in just about all of my socket code; errno values are easier to handle
than signals (in fact, the first revision of the FAQ failed to mention
SIGPIPE in that context; I'd got so used to ignoring it...)
There is one situation where you should not ignore SIGPIPE; if you are
going to exec() another program with stdout redirected to a socket. In
this case it is probably wise to set SIGPIPE to SIG_DFL before doing
the exec().
(Continued on next question...)
Other Interview Questions
| 