Date: Thu, 10 Jun 2004 22:53:14 -0700 From: Sean McNeil <sean@mcneil.com> To: Daniel Eischen <eischen@vigrid.com> Cc: freebsd-threads@freebsd.org Subject: Re: signal handler priority issue Message-ID: <1086933194.38839.3.camel@server.mcneil.com> In-Reply-To: <Pine.GSO.4.10.10406110115190.10340-100000@pcnet5.pcnet.com> References: <Pine.GSO.4.10.10406110115190.10340-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2004-06-10 at 22:29, Daniel Eischen wrote:
> On Thu, 10 Jun 2004, Sean McNeil wrote:
>
> > On Thu, 2004-06-10 at 21:55, Daniel Eischen wrote:
> > > On Thu, 10 Jun 2004, Sean McNeil wrote:
> > >
> > > > Here is what I see:
> > > >
> > > > master thread calls pthread_kill with SIGUSR1 and waits on semaphore.
> > > > other thread gets signal and calls sem_post. It yields the scheduler.
> > >
> > > This is fine as long as this thread doesn't get a signal
> > > until after sem_post(). Being signal safe doesn't mean
> > > that other threads can't be scheduled.
> > >
> > > > master thread gets semaphore and continues on it's way.
> > > > master thread calls pthread_kill with SIGUSR2 and keeps going.
> > >
> > > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1086933194.38839.3.camel>