At Wed, 21 Jul 2004 13:15:07 +0200, marco_g wrote: > > Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > However, I have a big concern: > > > > I have doubts if calling console_exit, and thus driver_fini, is safe > > at all from a signal handler. You might have to set some global flag, > > possibly protected by a spin lock (not mutex, I guess), which is then > > checked periodically by some other thread. > > Can't I use conditions instead?
Unfortunately not: 32578 It is not safe to use the pthread_cond_signal( ) function in a signal handler that is invoked 32579 asynchronously. Even if it were safe, there would still be a race between the test of the Boolean 32580 pthread_cond_wait( ) that could not be efficiently eliminated. 32581 Mutexes and condition variables are thus not suitable for releasing a waiting thread by signaling 32582 from code running in a signal handler. It's also questionable if you really want another thread to wait on a condition all the time. OTOH, there probably is no suitable other thread. So, if we need another thread, then that's ok. But block signals for all other threads, and have that thread also handle the signals you want to catch. That's best because then memory is already synchronized. Having that thread sleep most of the time and check for the volatile sig_atomic_t should_we_die; global flag every second should be ok. A max delay of 1 second at kill is acceptable, IMHO. Thanks, Marcus _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd