[Python-Dev] Re: Signal-resistant code (was: Two random and nearly unrelated ideas)
Oren Tirosh
oren-py-d@hishome.net
Fri, 6 Sep 2002 19:54:49 +0300
On Fri, Sep 06, 2002 at 05:09:16PM +0200, Jack Jansen wrote:
> Could we connect signals to semaphores or locks or something
> like that? That would allow you to do the two things that i
> think are worth doing in a signal handler: setting a flag and/or
> making some other part of the code wake up.
Signal handlers and locks don't mix well. A signal handler can't grab a
lock. The signal handler can't wait for the lock to be released because
it has interrupted the code holding it. The traditional way this has been
handled is with a global "interrupt enable" flag. Just like the good old
days of 8 bit micros and DOS when any application could clear the
interrupt flag :-)
If Queue.Queue sets up a signal critical section as well as getting the
queue lock a signal could write to a Queue and wake up a thread waiting
on the other end.
> Only problem is that for completeness you would really want to
> wire up select-like functionality too, so that you could really
> have a single waiting mechanism.
If the program uses select as the central dispatcher you can set up a
pipe. The signal handler writes to one end and the other end is listed in
the select socket map. It's a simple way to handle an occasional event
like a child process dying or a SIGHUP telling you to reload the
configuration file. Do you want to use signals for more intensive tasks
like asynchronous I/O?
Oren