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

François Pinard pinard@iro.umontreal.ca
Wed, 04 Sep 2002 17:21:44 -0400

[Guido van Rossum]

> [Jack]
>> Hmm, and when I think of it I don't think it's even possible to restart 
>> safely. What if I do a read() on a socket, and I request more bytes 
>> than the available physical memory (but less than VM, of course)? The 
>> kernel simply doesn't have anywhere to store the bytes other than my 
>> buffer, and if it has to return EINTR then >POOF< these bytes are gone 
>> forever.
> I think that if any bytes have already been copied into your buffer,
> you don't get an EINTR, you get a short read.

I'm not fully familiar with all the details of this problem, it surely has
been in the air for quite a long time now (I might have first heard of it
while Taylor UUCP was being developed).  It might be dependent on the
underlying system.  If I'm not mistaken, this is Ian Taylor who introduced the
following Autoconf macro:

     If the system automatically restarts a system call that is
     interrupted by a signal, define `HAVE_RESTARTABLE_SYSCALLS'.

In GNU file utilities (now merged within the new GNU coreutils), Jim Meyering
uses restart wrappers for many I/O functions, so the idea of wrappers has been
maturing for a while, and is used in basic, heavily used programs.  However, I
did not look at such wrappers recently.  Python might probably wrap calls when
these are restartable, or transmit the error upwards for systems where calls
are not restartable.

François Pinard   http://www.iro.umontreal.ca/~pinard