Re: console-client signal handling

[Marcus Brinkmann]

At Wed, 21 Jul 2004 13:15:07 +0200,
marco_g wrote:
> 
> Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> 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