Re: Missing in sigaction
Re: Missing in sigaction
- Subject: Re: Missing in sigaction
- From: Tilghman Lesher <email@hidden>
- Date: Wed, 28 Mar 2012 02:07:36 -0500
On Tue, Mar 27, 2012 at 11:03 PM, Stephen J. Butler
<email@hidden> wrote:
> Because I'm bored, I spent a couple hours investigating this. If there
> is a bug (and I'm not convinced there is -- there's a lot I don't know
> about signal handling) then it's a bug when a SIGUSR1 arrives while
> another SIGUSR1 is executing. Take the attached code, for example.
>
> First, I tried to not do anything you aren't supposed to do in the
> signal handler. I was still seeing some dropped SIGUSR1s and missing
> pids. After reading a bunch of man pages, headers, and IEEE specs, I
> asked myself "What happens if I unblock SIGUSR1 while handling it?"
>
> Ahh ha, success! For me at least the attached code always handles all
> signals, and preserves si_pid. There is a race condition in that you
> could run into the previous problem if your signal arrives before
> sigprocmask() is called. Of course, now you have to be extra careful
> that your handler is re-entrant.
You should be able to achieve the same effect (without the identified
race condition) simply by adding SA_NODEFER to your sa_flags.
_______________________________________________
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