Use the runtime's main thread ID in the threading module.

[ericsnowcurrently]

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']

[ericsnowcurrently]

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]

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?

[ericsnowcurrently]

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]

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.