[issue31517] MainThread association logic is fragile

Change by STINNER Victor : -- components: +Subinterpreters ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31517] MainThread association logic is fragile

Eric Snow added the comment: probably a duplicate: issue #39042 "Use the runtime's main thread ID in the threading module." -- ___ Python tracker ___

[issue31517] MainThread association logic is fragile

STINNER Victor added the comment: bpo-37416 has been marked as a duplicate of this issue. It contains snippet.py to reproduce a bug. -- ___ Python tracker ___

[issue31517] MainThread association logic is fragile

STINNER Victor added the comment: Python internals already know who is the "main" thread: _PyRuntime.main_thread. It's maintained up to date, even after a fork, PyOS_AfterFork_Child() calls _PyRuntimeState_ReInitThreads() which does: // This was initially set in _PyRuntimeState_Init().

[issue31517] MainThread association logic is fragile

Change by Antoine Pitrou : -- nosy: +aldwinaldwin, fabioz, int19h, vstinner ___ Python tracker ___ ___ Python-bugs-list mailing

[issue31517] MainThread association logic is fragile

Change by Antoine Pitrou : -- versions: +Python 3.8, Python 3.9 -Python 3.6, Python 3.7 ___ Python tracker ___ ___ Python-bugs-list

[issue31517] MainThread association logic is fragile

Nick Coghlan added the comment: We had the quirks of import related threading deadlocks documented for a long time, not as a promise, but as a debugging aid (and a recommendation for "don't do that"). I'd see this as being similar: we'd document that if you're using the _thread module, or

[issue31517] MainThread association logic is fragile

Antoine Pitrou added the comment: I'm not sure this is an issue worth fixing, but I don't think it's a good idea to document such quirky semantics. -- ___ Python tracker

[issue31517] MainThread association logic is fragile

Antoine Pitrou added the comment: > That said, I do agree with Tim that the status quo isn't broken per se: we > renamed `thread` to `_thread` in Python 3 for a reason This is not caused by `_thread` specifically, but any background thread created by C code that might invoke Python code. The

[issue31517] MainThread association logic is fragile

Antoine Pitrou added the comment: > Is there a problem here? I haven't heard of anyone even wondering about this > before. This came while working on the PEP 556 implementation. -- ___ Python tracker

[issue31517] MainThread association logic is fragile

Nick Coghlan added the comment: One place where this came up recently is in working out precisely how a Python-level subinterpreter API will interact with the threading API: https://mail.python.org/pipermail/python-dev/2017-September/149566.html That said, I do agree with Tim that the status

[issue31517] MainThread association logic is fragile

Tim Peters added the comment: Is there a problem here? I haven't heard of anyone even wondering about this before. threading.py worries about Threads created _by_ threading.py, plus the magical (from its point of view) thread that first imports threading.py. Users mix in `_thread` threads,

[issue31517] MainThread association logic is fragile

Antoine Pitrou added the comment: Fixing this will require thinking out what the "main thread" of an interpreter really is. Is it the thread in which PyInterpreterState_New() is called? (note this is not the same thing as the "main thread" in the signal module, which is process-global)

[issue31517] MainThread association logic is fragile

Changes by Antoine Pitrou : -- nosy: +asvetlov, tim.peters ___ Python tracker ___ ___

[issue31517] MainThread association logic is fragile

New submission from Antoine Pitrou: The threading main_thread() instance is associated to the thread that first imports the threading module. In usual circumstances, this will indeed be the interpreter's main thread. However, it is not always the case. See attached reproducer. $ ./python