Skip to content

Commit d237b3f

Browse files
jdemeyermiss-islington
authored andcommitted
bpo-36601: clarify signal handler comment and remove unnecessary pid check. (GH-12784)
https://bugs.python.org/issue36601
1 parent d267ac2 commit d237b3f

File tree

2 files changed

+12
-15
lines changed

2 files changed

+12
-15
lines changed
Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
A long-since-meaningless check for ``getpid() == main_pid`` was removed
2+
from Python's internal C signal handler.

Modules/signalmodule.c

Lines changed: 10 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -73,11 +73,12 @@ class sigset_t_converter(CConverter):
7373
/*
7474
NOTES ON THE INTERACTION BETWEEN SIGNALS AND THREADS
7575
76-
When threads are supported, we want the following semantics:
76+
We want the following semantics:
7777
7878
- only the main thread can set a signal handler
79+
- only the main thread runs the signal handler
80+
- signals can be delivered to any thread
7981
- any thread can get a signal handler
80-
- signals are only delivered to the main thread
8182
8283
I.e. we don't support "synchronous signals" like SIGFPE (catching
8384
this doesn't make much sense in Python anyway) nor do we support
@@ -88,17 +89,17 @@ class sigset_t_converter(CConverter):
8889
We still have the problem that in some implementations signals
8990
generated by the keyboard (e.g. SIGINT) are delivered to all
9091
threads (e.g. SGI), while in others (e.g. Solaris) such signals are
91-
delivered to one random thread (an intermediate possibility would
92-
be to deliver it to the main thread -- POSIX?). For now, we have
93-
a working implementation that works in all three cases -- the
94-
handler ignores signals if getpid() isn't the same as in the main
95-
thread. XXX This is a hack.
92+
delivered to one random thread. On Linux, signals are delivered to
93+
the main thread (unless the main thread is blocking the signal, for
94+
example because it's already handling the same signal). Since we
95+
allow signals to be delivered to any thread, this works fine. The
96+
only oddity is that the thread executing the Python signal handler
97+
may not be the thread that received the signal.
9698
*/
9799

98100
#include <sys/types.h> /* For pid_t */
99101
#include "pythread.h"
100102
static unsigned long main_thread;
101-
static pid_t main_pid;
102103
static PyInterpreterState *main_interp;
103104

104105
static volatile struct {
@@ -326,11 +327,7 @@ signal_handler(int sig_num)
326327
{
327328
int save_errno = errno;
328329

329-
/* See NOTES section above */
330-
if (getpid() == main_pid)
331-
{
332-
trip_signal(sig_num);
333-
}
330+
trip_signal(sig_num);
334331

335332
#ifndef HAVE_SIGACTION
336333
#ifdef SIGCHLD
@@ -1328,7 +1325,6 @@ PyInit__signal(void)
13281325
int i;
13291326

13301327
main_thread = PyThread_get_thread_ident();
1331-
main_pid = getpid();
13321328
main_interp = _PyInterpreterState_Get();
13331329

13341330
/* Create the module and add the functions */
@@ -1739,7 +1735,6 @@ _PySignal_AfterFork(void)
17391735
* the interpreter had an opportunity to call the handlers. issue9535. */
17401736
_clear_pending_signals();
17411737
main_thread = PyThread_get_thread_ident();
1742-
main_pid = getpid();
17431738
main_interp = _PyInterpreterState_Get();
17441739
}
17451740

0 commit comments

Comments
 (0)