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, nanjekyejoannah, ncoghlan, pablogsal, pconnell, pitrou, tim.peters, vstinner
Date 2019-12-21.00:07:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1576886849.14.0.218777019521.issue36476@roundup.psfhosted.org>
In-reply-to
Content
So I see 3 things to address here:

1. Python daemon threads
2. Python threads created in atexit handlers
3. non-Python threads accessing the C-API

Possible solutions (starting point for discussion):

1. stop them at the point we stop waiting for non-daemon threads (at the beginning of finalization)
2. disallow them?  do one more pass of wait-for-threads?
3. cause all (external) attempts to access the C-API to fail once finalization begins

Regarding daemon threads, the docs already say "Daemon threads are abruptly stopped at shutdown." [1]  So let's force them to stop.  Can we do that?  If we *can* simply kill the threads, can we do so without leaking resources?  Regardless, the mechanism we currently use (check for finalizing each(?) time through the eval loop) mostly works fine.  The problem is when C code called from Python in a daemon thread blocks long enough that it makes C-API calls (or even the eval loop) *after* we've started cleaning up the runtime state.  So if there was a way to interrupt that blocking code, that would probably be good enough.

The other two possible solutions are, I suppose, a bit more drastic.  What are the alternatives?


[1] https://docs.python.org/3/library/threading.html#thread-objects
History
Date User Action Args
2019-12-21 00:07:29eric.snowsetrecipients: + eric.snow, tim.peters, ncoghlan, pitrou, vstinner, pconnell, pablogsal, nanjekyejoannah
2019-12-21 00:07:29eric.snowsetmessageid: <1576886849.14.0.218777019521.issue36476@roundup.psfhosted.org>
2019-12-21 00:07:29eric.snowlinkissue36476 messages
2019-12-21 00:07:28eric.snowcreate