diff --git a/pep-0475.txt b/pep-0475.txt index 503cda731..0ab8e9051 100644 --- a/pep-0475.txt +++ b/pep-0475.txt @@ -36,15 +36,17 @@ handle them. Examples of signals: * Putting the application in background (ex: press CTRL-z and then type the ``bg`` command) sends the ``SIGCONT`` signal. -Writing a signal handler is difficult, only "signal-safe" functions -can be called. For example, ``printf()`` and ``malloc()`` are not -signal-safe. When a signal is sent to a process calling a system -call, the system call fails with the ``EINTR`` error to give the -program an opportunity to handle the signal without the restriction on -signal safe functions. +Writing a signal handler is difficult, only "async-signal safe" +functions can be called. For example, ``printf()`` and ``malloc()`` +are not async-signal safe. When a signal is sent to a process calling +a system call, the system call can fail with the ``EINTR`` error to +give the program an opportunity to handle the signal without the +restriction on signal safe functions. Depending on the platform, on +the system call and the ``SA_RESTART`` flag, the system call may or +may not fail with ``EINTR``. -If the signal handler was set with the ``SA_RESTART`` flag set, the C -library retries some the system call instead of failing with +If the signal handler was set with the ``SA_RESTART`` flag set, the +kernel retries some the system call instead of failing with ``EINTR``. For example, ``read()`` is retried, whereas ``select()`` is not retried. The Python function ``signal.signal()`` clears the ``SA_RESTART`` flag when setting the signal handler: all system calls @@ -85,9 +87,12 @@ List of Python modules of the standard library which handle * ``socketserver`` * ``subprocess`` +Other programming languages like Perl, Java and Go already retry +system calls failing with ``EINTR``. -Use Case 1: Don't Bother of Signals ------------------------------------ + +Use Case 1: Don't Bother With Signals +------------------------------------- In most cases, you don't want to be interrupted by signals and you don't expect to get ``InterruptedError`` exceptions. For example, do @@ -192,10 +197,12 @@ 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. -If such applications exist, they must be fixed to handle signals -differently, to have a reliable behaviour on all platforms and all -Python versions. For example, use a signal handle which raises an -exception, or use a wakeup file descriptor. +If such applications exist, they are not portable and are subject to +race conditions (deadlock if the signal comes before the system call). +These applications must be fixed to handle signals differently, to +have a reliable behaviour on all platforms and all Python versions. +For example, use a signal handle which raises an exception, or use a +wakeup file descriptor. Applications should not call ``signal.siginterrupt(signum, False)`` anymore, since this call will raise an exception in Python 3.6.