Date: Thu, 10 Jun 2004 20:32:14 -0700 From: Sean McNeil <sean@mcneil.com> To: freebsd-threads@freebsd.org Subject: signal handler priority issue Message-ID: <1086924733.65671.81.camel@server.mcneil.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1086924733.65671.81.camel>