[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: console-client signal handling

From: Marcus Brinkmann
Subject: Re: console-client signal handling
Date: Wed, 21 Jul 2004 01:57:53 +0200
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Wed, 14 Jul 2004 22:44:33 +0200,
marco_g wrote:
> This patch fixes the problem.  Marcus, can I commit this patch?

A minor nit: Define the macro inside the main function, just before
using it, and maybe undef it afterwards.

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.

Usually, with threads, you get extra problems with signal handling.
But for a simple handler that just causes a flag to be set or an
exit() to be triggered I don't think it matters.  Still, might be
worth to block signals for all threads except the main thread.  Maybe.
I have not thought about it much at all.  Also depends on the handler
code of course.

The reason I am careful here is that you don't know what's going on
inside a driver, and if you terminate it, it might want to communicate
with some worker threads for cleanup, and that won't work if it's that
worker thread which is currently running in the signal handler trying
to call driver_fini, for example.  Also, there are a whole slew of
functions that are not safe to call from within a signal handler, for
example malloc().  Another function I'd be careful about is dlclose,
which is used in driver_fini().

So, this might need more work.  There was a reason I didn't add it
earlier :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]