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

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