[Python-Dev] Re: Signal-resistant code

Oren Tirosh oren-py-d@hishome.net
Thu, 5 Sep 2002 23:27:16 +0300


On Thu, Sep 05, 2002 at 11:01:14AM -0400, Guido van Rossum wrote:
> > > I have never understood why a child dying should send a signal.
> > > You can poll for the child with waitpid() instead.
> > 
> > You're assuming too much about the structure of the program using
> > child processes. The code that starts the child process may not be
> > in control of the Python program counter by the time it ends. It's
> > useful to be able to leave a signal handler to clean up the zombie
> > process by waitpid().
> 
> I admit that I hate signals so badly that whenever I needed to wait
> for a child to finish I would always structure the program around this
> need (even when coding in C).

Ummm... if you really hate signals that much perhaps you to step aside 
from this particular discussion? Naturally, you will get to pronounce on 
the results that come out of it (if any ;-)


    Westley:  No, no. We have already succeeded.  I mean, what are 
        the three terrors of the fire swamp?  One, the flame spurt - no 
        problem - there's a popping sound preceding each.  We can avoid 
        that.  Two, the lightning sand which you were clever enough to 
        discover what that looks like, so in the future we can avoid that 
        too.

                     (from "The Princess Bride" by William Goldman)

So what are the three problems of signals?  

One - what calls are allowed by the platform inside a signal handler.
No problem.  Nobody suggested actually executing Python code inside a
signal handler so we don't need to be worried about user code. The C
handler doesn't call anything unusual, just sets flags.  This should work 
on all platforms.

Two - Interruptible system calls.  If all Python I/O calls are wrapped
inside restarting wrappers this should be solved. If the system's libc
wraps them it can be disabled by SA_RESTART (posix) or siginterrupt (BSD).
On some systems read and recv return a short buffer instead of EINTR. This 
can be safely ignored because it only happens for pipes and sockets where 
this is a valid result. AFAIR it's guaranteed not to happen on regular 
files so we won't be tricked into believing they reached EOF.  Are there 
any systems where system calls are interruptible but not restartable 
in any way without data loss? 

Three - Threads playing "who gets the signal".  The Python signal module
has a hack that appears to work on all relevant platform - ignore the
signal if getpid() isn't the main thread.

	Oren


Buttercup:  Westley, what about the R.O.U.S.'s?
Westley:  Rodents Of Unusual Size? I don't think they exist.

	...