signal handler priority issue

[Sean McNeil]

I'm working on kse support for gcc/gcj/gij and ran into an interesting
problem with signals:

Each thread installs a signal handler for synchronization.  This signal
handler does a sem_post() to inform it has suspended then goes into a
sigsuspend() loop waiting for a signal that has no handler attached to
it.  So we have

SIGUSR1 - signal handler attached to suspend the thread
SIGUSR2 - no signal handler but waited on in sigsuspend() within the
above handler.

When you want to have exclusive access, you loop through and stop each
thread by sending the SIGUSR2 and wait on the semaphore it posts to. 
Then you do your thing.  When done, you signal each thread with SIGUSR2.

The problem I'm seeing is that the signal handler doesn't have
pririority thus it goes to sleep on the sem_post and the SIGUSR2 signal
is lost because it happens before the sigsuspend() is invoked.

I think there is something missing or not functioning in sem_post that
should prevent the signal handler from losing the cpu.  I see there is
an enter/exit critical in there.  Should that prevent it from context
switching?  It would appear not in that exiting a critical section will
cause a yield.

Any help on figuring out how to fix this would be appreciated.  Perhaps
someone more familiar with kse can tell me how to go about changing it
so that a signal handler cannot cause a yield.  Perhaps something in
_thr_sig_handler?

TIA,
Sean