On Tue, Mar 27, 2012 at 11:03 PM, Stephen J. Butler <stephen.butler@gmail.com> 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app... This email sent to site_archiver@lists.apple.com