Re: SIGPIPE and SIG_IGN
Re: SIGPIPE and SIG_IGN
- Subject: Re: SIGPIPE and SIG_IGN
- From: Terry Lambert <email@hidden>
- Date: Mon, 18 Jun 2007 17:30:28 -0700
On Jun 18, 2007, at 4:25 PM, Glenn Anderson wrote:
At 4:09 pm -0700 18/6/2007, email@hidden wrote:
Hello, all ...
In my adventures of making our app also work on Mac OSX (10.4.9,
Intel and PPC), i've discovered that I occasionally get SIGPIPE
signals. This would be fine, except that I specifically ignore
them like this:
// set up our signal handlers
signal( SIGINT, signal_handler );
signal( SIGTERM, signal_handler );
#ifndef WIN32
signal( SIGPIPE, SIG_IGN );
#endif
... so my question is: why do I still get SIGPIPE signals, which
make my program go boom? What else do I need to do such that
SIGPIPE is actually ignored? I don't _always_ get them, but they
come up often enough to be a problem.
SIGPIPE is a per-thread signal, so you need to do signal( SIGPIPE,
SIG_IGN ) on every thread dealing with the relevant sockets.
Alternatively you can use setsockopt() with SOL_SOCKET and
SO_NOSIGPIPE to turn off SIGPIPE for a socket.
Actually, SIGPIPE is raised via psignal in all but one case; that case
is a EXC_UNIX_BAD_PIPE exception being raised (which we never raise; I
should delete this case entry from the switch statement at some point,
I guess).
So this is all psignal() generated, with a flavor argument of 0, which
means it's per process, and the thread that gets signalled will be
whatever thread is the current thread at the front of the list of
active threads for the process.
This also means that the signal will not get sent if you are ignoring
it, and it's in your process signal mask (sigaction() is generally
preferred to calling signal(), but either should work).
Unless there's a library mucking with signals behind your back, you'd
need to provide a reproducible case of getting the signal in a cut-
down program in a bug report for us to help you out with your
problem. If you are using per-thread signals, you have to program a
very specific way for this to work (see the O'Reilly pthreads book for
details), since there's a lot of "behaviour is undefined" type
behaviours when mixing thread signal masks and process masks.
It should also be noted that when a signal is raised, it may not end
up interrupting the operation in progress, since it may have run to
completion by the time you get back up to the kernel/user boundary to
hit the trampoline (we are like True64 UNIX in this regard, which is
also Mach-based and also uses Mach ASTs for signal delivery).
So if the signal happens before you ignore it, there's a small window
in which it's possible for the signal to hit you.
If you bug report this, make sure that you make it clear as to whether
this is a pipe, a socket, a named pipe, or a UNIX domain socket that's
triggering it.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden