Marcus Brinkmann <[EMAIL PROTECTED]> writes: > 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.
Ok. I just had cthreads in mind. AFAIK there is no problem with using the libcthread condition_signal(). Or don't you want to use that because we will switch to pthreads eventually? > 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; Unfortunately there is not a single thread that is active in the console client (libcons gets control of the main thread). So I will make a new thread for this. I will implement this as you proposed now. > global flag every second should be ok. A max delay of 1 second at kill is > acceptable, IMHO. Absolutely. AFAIK signals are not reliable anyway. Thanks, Marco _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd
