Eric Snow <ericsnowcurren...@gmail.com> added the comment:
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 ---------- nosy: +nanjekyejoannah, ncoghlan, pablogsal, pitrou, tim.peters, vstinner _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36476> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
