Description

ericsnowcurrently

opened on Dec 13, 2019

Issue body actions

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

1. ericsnowcurrently commented on Dec 13, 2019

   

   ericsnowcurrently

   on Dec 13, 2019

   MemberAuthor

   More actions

   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.
2. ericsnowcurrently

   added

   3.9 (EOL)end of lifeend of life

   stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Dec 13, 2019
3. ericsnowcurrently commented on Dec 17, 2019

   

   ericsnowcurrently

   on Dec 17, 2019

   MemberAuthor

   More actions

   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?
4. ericsnowcurrently commented on Dec 20, 2019

   

   ericsnowcurrently

   on Dec 20, 2019

   MemberAuthor

   More actions

   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.
5. ericsnowcurrently

   added

   3.8 (EOL)end of lifeend of life

   release-blocker

   on Dec 20, 2019
6. ambv commented on Feb 25, 2020

   

   ambv

   on Feb 25, 2020

   Contributor

   More actions

   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.
7. ambv

   removed

   release-blocker

   on Feb 25, 2020
8. ezio-melotti

   transferred this issue fromon Apr 10, 2022
9. serhiy-storchaka

   added this to Threading issues 🧵on May 20, 2022
10. schneeemensch commented on Jul 19, 2023

    

    schneeemensch

    on Jul 19, 2023

    More actions

    Hi,

    Are there any plans to resolve this?
    I ran into this issue by trying to use the coverage package inside a Python sub-interpreter.
    The coverage package is trying to add a signal.signal() handler to catch potential SIGTERM signals.
    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 signal and threading package lead to this guard failing and an exception while adding the signal handler.
11. aisk commented on Jun 4, 2024

    

    aisk

    on Jun 4, 2024

    Member

    More actions

    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.

Issue actions