This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients vstinner
Date 2019-05-24.08:08:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1558685337.89.0.451873883908.issue37031@roundup.psfhosted.org>
In-reply-to
Content
Currently, signalmodule.c tracks the "main thread" and the "main interpreter":

    main_thread = PyThread_get_thread_ident();
    main_interp = _PyInterpreterState_Get();

This information is already tracked in the global _PyRuntime variable which is updated at fork by _PyRuntimeState_ReInitThreads() (called by PyOS_AfterFork_Child).

Attached PR removes main_thread and main_interp from signalmodule.c, to reuse _PyRuntime. It should help to ensure that Python remains consistent (less risk of inconsistency if one variable is updated, but not the other).

By the way, _PyInterpreterState_DeleteExceptMain() is called before _PyRuntimeState_ReInitThreads(). _PyInterpreterState_DeleteExceptMain() acquires runtime->interpreters.mutex, whereas this lock is reset by _PyRuntimeState_ReInitThreads(). Maybe I introduced this bug recently when I refactored code, I don't know. But it sounds like a bug as well.

Note: PyOS_AfterFork_Child() doesn't update runtime->interpreters->main, but os.fork() raises a RuntimeError if it's not called from the main interpreter. So it's fine.
History
Date User Action Args
2019-05-24 08:08:57vstinnersetrecipients: + vstinner
2019-05-24 08:08:57vstinnersetmessageid: <1558685337.89.0.451873883908.issue37031@roundup.psfhosted.org>
2019-05-24 08:08:57vstinnerlinkissue37031 messages
2019-05-24 08:08:57vstinnercreate