Issue #8407: The signal handler writes the signal number as a single byte

instead of a nul byte into the wakeup file descriptor. So it is possible to
wait more than one signal and know which signals were raised.

2 files changed, 11 insertions, 3 deletions

diff --git a/Doc/library/signal.rst b/Doc/library/signal.rst
index 473eda2807..68a5d2c014 100644
--- a/Doc/library/signal.rst
+++ b/Doc/library/signal.rst
@@ -262,13 +262,17 @@ The :mod:`signal` module defines the following functions:
 
 .. function:: set_wakeup_fd(fd)
 
-   Set the wakeup fd to *fd*.  When a signal is received, a ``'\0'`` byte is
-   written to the fd.  This can be used by a library to wakeup a poll or select
-   call, allowing the signal to be fully processed.
+   Set the wakeup file descriptor to *fd*.  When a signal is received, the
+   signal number is written as a single byte into the fd.  This can be used by
+   a library to wakeup a poll or select call, allowing the signal to be fully
+   processed.
 
    The old wakeup fd is returned.  *fd* must be non-blocking.  It is up to the
    library to remove any bytes before calling poll or select again.
 
+   Use for example ``struct.unpack('%uB' % len(data), data)`` to decode the
+   signal numbers list.
+
    When threads are enabled, this function can only be called from the main thread;
    attempting to call it from other threads will cause a :exc:`ValueError`
    exception to be raised.
diff --git a/Doc/whatsnew/3.3.rst b/Doc/whatsnew/3.3.rst
index 14f06af802..37f96ce948 100644
--- a/Doc/whatsnew/3.3.rst
+++ b/Doc/whatsnew/3.3.rst
@@ -131,6 +131,10 @@ signal
   * :func:`~signal.sigpending`: examine pending functions ;
   * :func:`~signal.sigwait`: wait a signal.
 
+* The signal handler writes the signal number as a single byte instead of
+  a nul byte into the wakeup file descriptor. So it is possible to wait more
+  than one signal and know which signals were raised.
+
 
 Optimizations
 =============