[Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

[Dan Stromberg]

On Sun, Aug 31, 2014 at 3:28 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Victor Stinner wrote:
>>
>> As written in the PEP, if you want to be notified of the signal, set a
>> signal handler which raises an exception.
>
> I'm not convinced that this covers all possible use cases.
> It might be all right if you have control over the signal
> handler, but what if you don't?
>
> I think it's best if the functions in the os module remain
> thin wrappers that expose the OS functionality as fully and
> directly as possible. Anything else should be provided
> by higher-level facilities.

I'm inclined to agree about keeping the os module thin.  If we were to
recreate Python today, from scratch, it might make sense to hide this
by default, but now there's almost certainly code out there that
depends on the current behavior.

But I also agree that it's hard to pin down which higher level Python
library calls are going to be using system calls.  My
http://stromberg.dnsalias.org/~strombrg/pypty/ program had a problem
with window resizing for a while (SIGWINCH), and although I use it
pretty much daily now without problems, I'm still not sure I got 100%
of the possibilities covered.

Fortunately, wrapping a system call can be as simple as:

def retry_on_eintr(function, *args, **kw):
    '''
    Retry a system call until one of the following happens:
    1) It succeeds
    2) It errors with something other than EINTR
    '''

    while True:
        try:
            return function(*args, **kw)
        except OSError:
            nothing, extra, nothing2 = sys.exc_info()
            dummy = nothing
            dummy = nothing2
            if extra.errno == errno.EINTR:
                continue
            else:
                raise

Note that os.read() and os.write() need different handling.