[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?