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

[Oren Tirosh]

On Wed, Sep 04, 2002 at 09:25:01AM -0400, Guido van Rossum wrote:
> > After that the wrappers can be modified to retry the call on EINTR.
> 
> But that's not always what you want to happen!  E.g. if an app is
> blocked on a read and uses an alarm to bail out of the read.

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.

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.

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

	Oren


I/O, I/O, it's off to work we go...

	The seven dwarfs