[Python-Dev] Re: Signal-resistant code (was: Two random and nearly unrelated ideas)

Guido van Rossum guido@python.org
Thu, 05 Sep 2002 11:01:14 -0400


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

> > But if you have a suggestion for how to fix this particular issue, I'd
> > be happy to look it over, since this *is* something some people do.
> 
> Of course people do it - it's documented and it works.

Barely.  This thread started when you pointed out the problems with
using signals.  I've always been reluctant about the fact that we had
a signal module at all -- it's not portable (no non-Unix system
supports it well), doesn't interact well with threads, etc., etc.;
however, C programmers have demanded some sort of signal support and I
caved in long ago when someone contributed a reasonable approach.  I
don't regret it like lambda, but I think it should only be used by
people who really know about the caveats.

> > See above.  I see half your point; people wanting this tend to use
> > signals and it causes breakage.
> 
> Polling is not what I'd call "getting notification of asynchronous events".
> If it causes breakage it could be because people either use it incorrectly
> or the signal support on the underlying system is broken. In Linux it isn't
> broken. If it's broken on other Python platforms I don't see why it
> shouldn't be well-supported on the platforms that aren't.

I meant in Python.  The I/O problems make signals hard to use.

> Has anyone here actually tried to use signal.signal ?

Yes.

> Code in signal handlers is executed at some arbitrary point in the
> program and the programmer should be aware of this and only do so
> simple things like setting a flag or appending to a list.

Unfortunately the mechanism doesn't enforce this.  I wish we could
invent a Python signal API that only lets you do one of these simple
things.

--Guido van Rossum (home page: http://www.python.org/~guido/)