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

<p dir="ltr">Extract of the PEP:</p>
<p dir="ltr">Backward Compatibility:</p>
<p dir="ltr">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.</p>

<p dir="ltr">Victor</p>