signal handler priority issue

[David Xu]

Can you provide some code to demostrate the problem ? I have interest.

David Xu

Sean McNeil wrote:
> 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
> 
> 
> _______________________________________________
> freebsd-threads at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> To unsubscribe, send any mail to "freebsd-threads-unsubscribe at freebsd.org"
>