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

[Matthew Woodcraft]

Victor Stinner  <victor.stinner at gmail.com> wrote:
> HTML version:
> http://legacy.python.org/dev/peps/pep-0475/

> PEP: 475
> Title: Retry system calls failing with EINTR

I think the proposed design for how Python should behave is a good
one.

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
exit.)

-M-