[Python-Dev] Re: Signal-resistant code (was: Two random and nearly unrelated ideas)
Guido van Rossum
Wed, 04 Sep 2002 16:05:22 -0400
> If I use a module that spawns an external process and uses SIGCHLD to be
> informed of its termination why should my innocent code that just reads
> lines from a file suddenly break? In C I can at least restart the
> operation after an EINTR but file.readline cannot even be properly
> restarted because the buffering and file position is all messed up.
I have never understood why a child dying should send a signal. You
can poll for the child with waitpid() instead.
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.
> The example you gave of bailing out of a read with a signal can be done
> using other techniques such as non-blocking I/O (which is, IMHO, a much
> cleaner way to do it).
> Getting an notification of a child process terminating or other
> asynchronous events can only be done using signals and is currently
> dangerous because it will break code using I/O.
See above. I see half your point; people wanting this tend to use
signals and it causes breakage.
> > > interference to Python code by signals. Any other problems I should
> > > be aware of?
> > There's no way to sufficiently test a program that uses signals. The
> > signal handler cannot touch *any* data, which makes it pretty useless.
> In order to be useful a signal handler needs to be able to set one bit.
> The next time the ticker expires this bit will be checked.
> If an I/O operation was interrupted the Python signal handler can be
> executed immediately from the wrapper. When it returns the wrapper
> will resume the interrupted operation.
Is calling the Python signal handler from the wrapper always safe?
What if the Python signal handler e.g. closes the file or reads from
--Guido van Rossum (home page: http://www.python.org/~guido/)