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 eric.snow
Date 2019-03-29.21:59:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1553896742.19.0.478613119545.issue36479@roundup.psfhosted.org>
In-reply-to
Content
Currently when a thread acquires the GIL, it subsequently exits if the runtime is finalizing.  This helps with some cases like with stopping daemon threads.

This behavior should instead be triggered by the thread's interpreter finalizing rather than the runtime.  This implies the following changes:

* in Py_EndInterpreter() move "interp-finalizing = 1;" to right after the call to "wait_for_thread_shutdown()"
* in Py_FinalizeEx() add "interp-finalizing = 1;" right after the call to "wait_for_thread_shutdown()"
* update _PyEval_EvalFrameDefault() (the eval loop) to check "interp->finalizing" instead of the runtime
* likewise update PyEval_RestoreThread() (as well as PyEval_AcquireThread() and PyEval_AcquireLock(); see #36475)

The check will actually need to change from this:

  if (_Py_IsFinalizing() && !_Py_CURRENTLY_FINALIZING(tstate)) {

to look like this:

  if (interp->finalizing && !_Py_CURRENTLY_FINALIZING(tstate)) {

If we could guarantee that only the main thread will ever call Py_FinalizeEx() then it would look more like this:

  if (interp->finalizing && tstate.id != _PyRuntime.main_thread {
History
Date User Action Args
2019-03-29 21:59:02eric.snowsetrecipients: + eric.snow
2019-03-29 21:59:02eric.snowsetmessageid: <1553896742.19.0.478613119545.issue36479@roundup.psfhosted.org>
2019-03-29 21:59:02eric.snowlinkissue36479 messages
2019-03-29 21:59:02eric.snowcreate