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

[Matthew Woodcraft]

In article <CAMpsgwabYhXB0OG3UhdX=FUCYOnAJGzpwd-g8sTdauKjzpJAMQ at mail.gmail.com>,
Victor Stinner  <victor.stinner at gmail.com> wrote:
>2014-09-02 23:03 GMT+02:00 Matthew Woodcraft <matthew at woodcraft.me.uk>:
>> In any case I think PEP 475 should be explaining what is going to happen
>> to signal.siginterrupt(). Will setting flag=True be supported?

> I first proposed to deprecate the function, but Charles-François
> thinks that it's unrelated to the PEP (it can be addressed later).

> The function will still be available and work.

>> If so, will doing so change the behaviour of those parts of the stdlib which
>> have already been modified to retry after EINTR?

> I think that the stdlib should not handle InterruptedError exception
> anymore in the Python code, to simplify the code.

That seems good to me. I think it's worth writing in the PEP.

But if Python is going to provide its own higher-level model of signal
handling, then I think signal.siginterrupt() will need to be documented
in terms of that model; it should be saying something along the lines of
"if a signal arrives while Python is blocking in a system call then
InterruptedError will be raised", and I suppose it will need to say what
happens if the signal handler also raised an exception.


>> (I think it would be helpful if we could tell people "if you want the
>> old EINTR behaviour, just do this simple thing". And I suppose
>> siginterrupt flag=True is a candidate for that.)

> Why do you want the old behaviour?

Purely to avoid breaking existing programs, particularly in ways which
will require effort to fix.

I think Python's backward-compatibility rules are basically "the
behavior of an API must not change without going through the deprecation
process".

If we're going to be making an exception to that here, then it would be
much better to say "here's a simple change to make to keep your old
program working", rather than "please rewrite your fiddly
signal-handling code to use more modern techniques", however much nicer
those modern techniques are.

Or perhaps it would be better to not make an exception at all, and
instead add an 'interrupt_syscalls' boolean keyword argument to
signal.signal(), while strongly recommending that people set it False.

-M-