Repository navigation
Use the runtime's main thread ID in the threading module. #83223
Description
| BPO | 39042 |
|---|---|
| Nosy | @ambv, @ericsnowcurrently |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2019-12-13.22:21:22.139>
labels = ['3.8', 'type-bug', 'library', '3.9']
title = "Use the runtime's main thread ID in the threading module."
updated_at = <Date 2020-02-25.12:06:41.723>
user = 'https://github.com/ericsnowcurrently'bugs.python.org fields:
activity = <Date 2020-02-25.12:06:41.723>
actor = 'lukasz.langa'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2019-12-13.22:21:22.139>
creator = 'eric.snow'
dependencies = []
files = []
hgrepos = []
issue_num = 39042
keywords = ['3.8regression']
message_count = 4.0
messages = ['358362', '358557', '358727', '362634']
nosy_count = 2.0
nosy_names = ['lukasz.langa', 'eric.snow']
pr_nums = []
priority = 'high'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue39042'
versions = ['Python 3.8', 'Python 3.9']
Activity
ericsnowcurrently commentedon Dec 13, 2019
The threading module has a "main_thread()" function that returns a Thread instance for the "main" thread. The main thread is the one running when the runtime is initialized and has a specific role in various parts of the runtime. Currently the threading module instead uses the ID of the thread where the module is imported for the first time. Usually this isn't a problem. (perhaps only in embedding cases?)
Since 3.8 we store the ID of the thread where the runtime was initialized (_PyRuntime.main_thread). By using this in the threading module we can be consistent across the runtime about what the main thread is.
This is particularly significant because in 3.8 we also updated the signal module to use _PyRuntime.main_thread (instead of calling PyThread_get_thread_ident() when the module is loaded). See bpo-38904 (#83085).
We should also consider backporting this change to 3.8, to resolve the difference between the threading and signal modules.
ericsnowcurrently commentedon Dec 17, 2019
Hmm, I wonder if this should be considered a regression in 3.8. As demonstrated in bpo-38904, the following code changed behavior as of 3.8, under certain conditions:
Note the specific conditions:
Also note that the only other help we offer is a "private" function in the C-API: _PyOS_IsMainThread(). That would have given the correct answer, but we do not expect users to call it, and it doesn't help them from Python code anyway.
Also, the same problem existed pre-3.8 if signal and threading were imported in different threads before the above script ran.
Finally, I'm (mostly) confident that this would be a backward-compatible fix.
What do you think about this being a 3.8 regression, Łukasz?
ericsnowcurrently commentedon Dec 20, 2019
I don't see a reason not to consider this is a regression.
The only problem with the fix would be for any users that rely on the inaccurate reporting of the threading module. Considering that possibly includes only some embedders (and folks using _thread module directly), I expect the impact would be extremely small. A porting entry in the whats-new doc.
ambv commentedon Feb 25, 2020
I agree this should be fixed. Since we've already released 3.8.1 and 3.8.2 with this behavior it's hard to justify blocking releases on this, though.
schneeemensch commentedon Jul 19, 2023
Hi,
Are there any plans to resolve this?
I ran into this issue by trying to use the
coveragepackage inside a Python sub-interpreter.The
coveragepackage is trying to add asignal.signal()handler to catch potentialSIGTERMsignals.This check is correctly guarded by a
if (threading.current_thread() == threading.main_thread()):check to ensure that the signal is never added from a different thread than the Main Thread.Unfortunately, the different understandings of MainThread by the
signalandthreadingpackage lead to this guard failing and an exception while adding the signal handler.aisk commentedon Jun 4, 2024
Hi, I see #114839 solved this issue and has been released in 3.13b1, but that PR is mainly for free-thread features, so it wouldn't have been backported to older versions.
So what should we do for this issue? Maybe we can only backport the changes for the main thread ID, but this might cause conflicts with other backports.