signal handler priority issue
Daniel Eischen
eischen at vigrid.com
Fri Jun 11 06:06:09 GMT 2004
On Thu, 10 Jun 2004, Sean McNeil wrote:
> On Thu, 2004-06-10 at 22:29, Daniel Eischen wrote:
> > > >
> > > > It can't keep going if there is a possibility that it can
> > > > send the same thread another SIGUSR2.
> > >
> > > I don't follow. Sorry.
> >
> > If the master thread does:
> >
> > for (i = 0; i < 4; i++) {
> > pthread_kill(slave, SIGUSR1);
> > sem_wait(&slave_semaphore);
> > pthread_kill(slave, SIGUSR2);
> > }
> >
> > You can see that there is a potential race condition where
> > the slave thread gets SIGUSR1 and SIGUSR2 very close together.
> > It is even possible to get them together in one sigsuspend()
> > (if they are both unmasked in the suspend mask).
> >
> > You could fix the race by blocking SIGUSR1 from within
> > the signal handler (like I described in my last email).
>
> I take it then that when a signal handler is invoked that it's signal
> isn't masked while running. It isn't like a standard hardware interrupt
> then. I'm trying as you suggest and will post results.
Like I said before, it depends on the mask of the installed
signal handler (sigact.sa_mask). You should use sigaction()
and not signal() to get the desired behavior.
You're other output looked strange. I was expecting the
"restart" count to start at 1, not 2.
--
Dan Eischen
More information about the freebsd-threads
mailing list