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

[Guido van Rossum]

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

Yes.

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

OK.

> 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
it?

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