Re: When to call signal(...)
Re: When to call signal(...)
- Subject: Re: When to call signal(...)
- From: Douglas Davidson <email@hidden>
- Date: Fri, 10 May 2002 11:25:06 -0700
On Friday, May 10, 2002, at 10:57 AM, email@hidden wrote:
Actually, a signal handler is probably not the best way to handle this.
If you get a signal, your handler will be called, but the system call
that caused the signal should also return an error code if the signal
doesn't kill the program. It would be better to ignore the signal
(which will keep it from killing the program), and just check the error
code. (You need to check the error code anyway, so it's not like
there's new code involved.) Once the system call has returned, it
should be safe to disconnect the socket (assuming nothing else is
preventing it), and you can raise the Cocoa exception safely. (The rule
of thumb for signal handler functions is, do as little as possible;
ideally, do nothing. Signal handlers are one of the great ill-defined
areas of the system; it's best to avoid them where possible.)
To ignore the signal, write "signal(SIGPIPE, SIG_IGN)". (If you
really want a signal handler, you'd pass the address of the handler
instead of SIG_IGN. To get the address, just write the name of the
function. The handler itself would take a single "int" argument--the
signal number--and "return" void.)
This is excellent advice; I have just one thing to add, which is that
there is a socket option being planned that will allow the suppression
of the SIGPIPE signal on a per-socket basis. For now, however, you can
ignore it globally as suggested.
Douglas Davidson
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.