[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: console-client signal handling
From: |
Marco Gerards |
Subject: |
Re: console-client signal handling |
Date: |
Wed, 21 Jul 2004 16:57:55 +0200 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> writes:
> 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.
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
- console-client signal handling, Marco Gerards, 2004/07/14
- Re: console-client signal handling, Marcus Brinkmann, 2004/07/20
- Re: console-client signal handling, Marco Gerards, 2004/07/22
- Re: console-client signal handling, Marcus Brinkmann, 2004/07/22
- Re: console-client signal handling, Roland McGrath, 2004/07/27
Re: console-client signal handling, Roland McGrath, 2004/07/21