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

Dan Stromberg drsalists at gmail.com
Mon Sep 1 05:14:50 CEST 2014

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:
            return function(*args, **kw)
        except OSError:
            nothing, extra, nothing2 = sys.exc_info()
            dummy = nothing
            dummy = nothing2
            if extra.errno == errno.EINTR:

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

More information about the Python-Dev mailing list