Repository navigation
Use the runtime's main thread ID in the threading module. #83223
Description
Activity
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.
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:
import signal import threading def int_handler(): ... if threading.current_thread() == threading.main_thread(): signal.signal(signal.SIGINT, int_handler)
Note the specific conditions:
- threading and signal have not been imported yet
- the current thread when the module is *imported* is not the main thread (this only affects folks embedding Python)
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?
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.
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.
Hi,
Are there any plans to resolve this?
I ran into this issue by trying to use thecoveragepackage inside a Python sub-interpreter.
Thecoveragepackage is trying to add asignal.signal()handler to catch potentialSIGTERMsignals.
This check is correctly guarded by aif (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.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.
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:
bugs.python.org fields: