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

[Oren Tirosh]

On Wed, Sep 04, 2002 at 04:05:22PM -0400, Guido van Rossum wrote:
> > 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.

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

> 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.  Signal handling 
may have had some historical problems on some Unixes but I've never had any 
problem with it under Linux.  My previous messages more or less outline
my suggestion. I'll write a better summary.

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

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.

Has anyone here actually tried to use signal.signal ?

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

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.

	Oren