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