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

Victor Stinner  <vict...@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-

_______________________________________________
Python-Dev mailing list
Pyth...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/python-dev-ml%40activestate.com