[Python-Dev] Re: Signal-resistant code (was: Two random and nearly unrelated ideas)
Wed, 4 Sep 2002 12:01:43 -0400
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
I/O, I/O, it's off to work we go...
The seven dwarfs