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 eric.snow
Recipients Richard Warfield, eric.snow, vstinner
Date 2019-12-13.22:25:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1576275914.67.0.946957959481.issue38904@roundup.psfhosted.org>
In-reply-to
Content
Before 3.8, the "signal" module checked against the thread in which the module was initially loaded, treating that thread as the "main" thread.  That same was true (and still is) for the "threading" module.  The problem for both modules is that the Python runtime may have actually been initialized in a different thread, which is the actual "main" thread.

Since Python 3.8 we store the ID of the thread where the runtime is initialized and use that in the check the "signal" module does.  However, the "threading" module still uses the ID of the thread where it is first imported.  So your check against "threading.main_thread()" must be in code that isn't running in the same thread where you ran Py_Initialize().  It probably used to work because you imported "signal" and "threading" for the first time in the same thread.

So what next?

First, I've created issue39042 to address the current different meanings of "main thread".  That should resolve the discrepancy between the signal and threading modules.

Second, what can we do to help embedders make sure they are running their code in the main thread (e.g. when setting signals)?  Is there any C-API we could add which would have helped you here?
History
Date User Action Args
2019-12-13 22:25:14eric.snowsetrecipients: + eric.snow, vstinner, Richard Warfield
2019-12-13 22:25:14eric.snowsetmessageid: <1576275914.67.0.946957959481.issue38904@roundup.psfhosted.org>
2019-12-13 22:25:14eric.snowlinkissue38904 messages
2019-12-13 22:25:14eric.snowcreate