classification
Title: Use the runtime's main thread ID in the threading module.
Type: behavior Stage: needs patch
Components: Library (Lib) Versions: Python 3.9, Python 3.8
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: eric.snow, lukasz.langa
Priority: high Keywords: 3.8regression

Created on 2019-12-13 22:21 by eric.snow, last changed 2020-02-25 12:06 by lukasz.langa.

Messages (4)
msg358362 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2019-12-13 22:21
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 issue38904.

We should also consider backporting this change to 3.8, to resolve the difference between the threading and signal modules.
msg358557 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2019-12-17 17:09
Hmm, I wonder if this should be considered a regression in 3.8.  As demonstrated in issue38904, 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?
msg358727 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2019-12-20 18:57
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.
msg362634 - (view) Author: Łukasz Langa (lukasz.langa) * (Python committer) Date: 2020-02-25 12:06
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.
History
Date User Action Args
2020-02-25 12:06:41lukasz.langasetpriority: release blocker -> high

messages: + msg362634
2019-12-20 18:57:08eric.snowsetpriority: normal -> release blocker
versions: + Python 3.8
messages: + msg358727

keywords: + 3.8regression
stage: test needed -> needs patch
2019-12-17 17:09:19eric.snowsetnosy: + lukasz.langa
messages: + msg358557
2019-12-13 22:21:22eric.snowcreate