[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/)