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

[Charles-François Natali]

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.