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

Charles-François Natali cf.natali at gmail.com
Mon Sep 1 13:25:53 CEST 2014

2014-09-01 12:15 GMT+01:00 Marko Rauhamaa <marko at pacujo.net>:

Charles-François Natali <cf.natali at gmail.com>:

Which raises an interesting question: what happens to the os.read() return value if SIGINT is received? There's no return value, a KeywordInterrupt exception is raised. The PEP wouldn't change this behavior. Slightly disconcerting... but I'm sure overriding SIGINT would cure that. You don't want to lose data if you want to continue running. As for the general behavior: all programming languages/platforms handle EINTR transparently. C doesn't. EINTR is there for a purpose.

Python is slightly higher level than C, right? I was referring to Java, go, Haskell...

Furthermore, that's not true: many operating systems actually restart syscalls by default (including Linux, man 7 signal):

""" Interruption of system calls and library functions by signal handlers If a signal handler is invoked while a system call or library function call is blocked, then either:

   * the call is automatically restarted after the signal handler

returns; or

   * the call fails with the error EINTR.

   Which of these two behaviors occurs depends on the interface

and whether or not the signal handler was established using the SA_RESTART flag (see sigaction(2)). The details vary across UNIX systems; below, the details for Linux. """

The reason the interpreter is subject to so many EINTR is that we explicitly clear SA_RESTART because the C-level signal handler must be handled by the interpreter to have a chance to run the Python-level handlers from the main loop.

There are many aspects of signal handling in Python that make it different from C: if you want C semantics, stick to C.

I do not want to have to put all blocking syscalls within a try/except loop: have a look at the stdlib code, you'll see it's really a pain and ugly. And look at the number of EINTR-related syscalls we've had.

More information about the Python-Dev mailing list