signal handler priority issue

[Sean McNeil]

On Thu, 2004-06-10 at 23:03, David Xu wrote:
> I think there is a race in GC_suspend_handler,
> code between sem_post and sigsuspend has race, let me demostrate:
> 
> Master : pthread_kill(slave1, SIGUSR1);
> Master : semwait
> Slave1 : sempost
> Master : semwait return
> Master : pthread_kill(slave, SIGUSR2);
> Master : pthread_kill(slave2, SIGUSR1);
> ...
> Slave1 : scheduler switched to slave1, found there
>           is SIGUSR2 in pending set
> Slave1 : invoke SIGUSR2 handler withinsa_handler
> Slave1 : SIGUSR2 handler return
> Slave1 : sigsuspend SIGUSR2
>           because SIGUSR2 was already handled, it hangs
>           in sigsuspend, and never return.
> 
> It seems the code has the race bug. I think you should
> use sigaction and set additional mask for SIGUSR1.
> code looks like this:
> 
> struct sigaction sa;
> 
> sigemptyset(&sa.sa_mask);
> sigaddset(&sa.sa_mask, SIGUSR2);
> sa.sa_handler = GC_suspend_handler;
> sigaction(SIGUSR1, &sa, NULL);
> 
> this code will block out SIGUSR2 in GC_suspend_handler,
> and when you call sigsuspend for SIGUSR2, it should return
> if there is SIGUSR2 pending or it SIGUSR2 comes later.

Actually, what I think is happening now is that the sigaction for
SIGUSR2 is being called but the sigsuspend isn't being release.