iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 475

This commit is contained in:
Victor Stinner 2014-07-29 22:10:53 +02:00
parent 07b6aa32ea
commit cdacf3fbad
1 changed files with 21 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
pep-0475.txt
View File

@ -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.