[issue36601] signals can be caught by any thread

Change by Gregory P. Smith : -- resolution: -> fixed stage: patch review -> commit review status: open -> closed type: -> enhancement versions: +Python 3.8 ___ Python tracker ___

[issue36601] signals can be caught by any thread

miss-islington added the comment: New changeset d237b3f0f61990c972b84c45eb4fe137db51a6a7 by Miss Islington (bot) (Jeroen Demeyer) in branch 'master': bpo-36601: clarify signal handler comment and remove unnecessary pid check. (GH-12784) https://github.com/python/cpython/commit/d237b3f0f61990

[issue36601] signals can be caught by any thread

Gregory P. Smith added the comment: PR is approved with automerge, just awaiting CI to give it the green light now. -- ___ Python tracker ___ _

[issue36601] signals can be caught by any thread

Change by Gregory P. Smith : -- assignee: -> gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36601] signals can be caught by any thread

Nathaniel Smith added the comment: Yeah, the check makes sense on a system like the comment says IRIX used to be, where getpid() actually returns a thread id *and* signals are delivered to all threads (wtf). But any modern system should do the POSIX thing, where getpid() returns the same valu

[issue36601] signals can be caught by any thread

Gregory P. Smith added the comment: We can remove ancient Irix and LinuxThreads hacks from our codebase. The best way to shake issues of this sort out is to remove it and watch for issues on supported buildbots and during beta releases. I don't expect any fallout from this one. Other place

[issue36601] signals can be caught by any thread

Eryk Sun added the comment: > Maybe a similar thing exists in Linux? Back in the late 90s, Linux implemented threads as 'processes' (LinuxThreads), but with shared resources such as virtual memory and file descriptors. (The Linux kernel's clone system call is highly composable in this regar

[issue36601] signals can be caught by any thread

Guido van Rossum added the comment: IIRC in SGI, getpid() would return the thread ID. They had a syscall that could create a new subprocess that would share or not share various resources (e.g. memory, signals, file descriptors) so by setting or clearing bits you could implement a continuum

[issue36601] signals can be caught by any thread

Change by STINNER Victor : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue36601] signals can be caught by any thread

Steve Dower added the comment: Looks like Guido added the original code about 25 years ago. Since he removed himself from the other thread during that discussion, I'm going to assume he's not interested in thinking about it any more. As the original comment says, it's a hack, but I guess the

[issue36601] signals can be caught by any thread

Jeroen Demeyer added the comment: Also note that the documentation of the signal module already has the correct wording: Python signal handlers are always executed in the main Python thread, even if the signal was received in another thread. -- _

[issue36601] signals can be caught by any thread

Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +12711 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-

[issue36601] signals can be caught by any thread

New submission from Jeroen Demeyer : Because of some discussion that is happening on #1583 I noticed this bit of code in the OS-level signal handler (set by the C function sigaction() or signal()): static void signal_handler(int sig_num) { /* See NOTES section above */ if (getpid() == main_pi