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