signal handler priority issue

Daniel Eischen eischen at vigrid.com
Fri Jun 11 06:43:06 GMT 2004


On Thu, 10 Jun 2004, Sean McNeil wrote:

> 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.

Because the handler is being called before sigsuspend() is
hit.

-- 
Dan Eischen



More information about the freebsd-threads mailing list