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

[Victor Stinner]

Le 1 sept. 2014 02:40, "Greg Ewing" <greg.ewing at canterbury.ac.nz> a écrit :
>
> Victor Stinner wrote:
>>
>> As written in the PEP, if you want to be notified of the signal, set a
signal handler which raises an exception.
>
>
> I'm not convinced that this covers all possible use cases.
> It might be all right if you have control over the signal
> handler, but what if you don't?

Ok, let's say that a syscall is interrupted by a signal, but rhe signal
doesn't raise an exception. So your program can only be interrupted if the
signal is received during a syscall, right? I don't think that such program
is reliable. Python should not promote such design. It should behave the
same if the signal is received during a CPU-bound function.

Extract of the PEP:

Backward Compatibility:

Applications relying on the fact that system calls are interruptedwith
``InterruptedError`` will hang. The authors of this PEP don'tthink that
such application exist.If such applications exist, they are not portable
and are subject torace conditions (deadlock if the signal comes before the
system call).These applications must be fixed to handle signals
differently, tohave a reliable behaviour on all platforms and all Python
versions.For example, use a signal handler which raises an exception, or
use awakeup file descriptor.For applications using event loops,
``signal.set_wakeup_fd()`` is therecommanded option to handle signals. The
signal handler writes signalnumbers into the file descriptor and the event
loop is awaken to readthem. The event loop can handle these signals without
the restrictionof signal handlers.

Victor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140901/16512d76/attachment-0001.html>