signal handler priority issue

Daniel Eischen eischen at vigrid.com
Fri Jun 11 04:55:21 GMT 2004


On Thu, 10 Jun 2004, Sean McNeil wrote:

> On Thu, 2004-06-10 at 21:19, Daniel Eischen wrote:
> > 
> > The critical section should prevent the signal handler
> > from being invoked.  Put some printf()'s in after the
> > sem_post() and in the signal handler().  The signal
> > handler printf()'s should always occur after the sem_post().
> > Plus, you shouldn't be getting that signal since it
> > should be masked until sigsuspend() is called.
> > 
> > Is it getting past sem_post() and into sigsuspend() or not?
> > If it is getting past sem_post(), then I don't think that is
> > your problem.
> 
> 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.

> Later, master calls pthread_kill with SIGUSR1 and waits on semaphore.
> other thread gets signal and calls sem_post.  It yields the scheduler.

Why is it getting SIGUSR1?  It is waiting for SIGUSR2, not
SIGUSR1.  You need to mask SIGUSR1 before the sem_post() and
until after the sigsuspend() on SIGUSR2.

> master thread gets semaphore and continues on it's way.
> master thread calls pthread_kill with SIGUSR2 and keeps going.
> Finally, master scheduler is done and yields the scheduler.
> other thread gets to run now and then it goes into sigsuspend waiting
> for SIGUSR2, but it never gets it because it wasn't masked until
> sigsuspend is called.
> threads are all hung.
> 
> The problem is that sem_post should not cause a reschedule of threads
> when inside a signal handler and it does.

Nope, that is allowable.  Please don't confuse signal safe with
"will not yield the CPU".  Also, on SMP, there are not guarantees
regardless!

I'm not saying that there isn't a bug somewhere, but don't go
reading more into what the requirements of sem_post() are.

-- 
Dan Eischen



More information about the freebsd-threads mailing list