[Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR
matthew at woodcraft.me.uk
Mon Sep 1 23:17:33 CEST 2014
Victor Stinner <victor.stinner at gmail.com> wrote:
> HTML version:
> PEP: 475
> Title: Retry system calls failing with EINTR
I think the proposed design for how Python should behave is a good
But I think this proposal needs to be treated in the same way as any
other backwards-incompatible change.
> Applications relying on the fact that system calls are interrupted
> with ``InterruptedError`` will hang. The authors of this PEP don't
> think that such application exist.
The authors are mistaken here. I have a program still running which was
designed around this behaviour.
My company won't be inconvenienced by this change because I can't
imagine the elderly program ever being ported to Python 3.
But I think it's very likely there are other such programs out there.
> If such applications exist, they are not portable and are subject to
> race conditions (deadlock if the signal comes before the system call).
The program is certainly not portable (which is not any kind of a
problem), and as pselect is unavailable there is indeed the usual
theoretical race (which has not been a problem in practice in the ten
years it's been running).
(The program handles SIGTERM so that it can do a bit of cleanup before
exiting, and it uses the signal-handler-sets-a-flag technique. The call
that might be interrupted is sleep(), so the program doesn't strictly
_rely_ on the existing behaviour; it would just become very slow to
More information about the Python-Dev