Repository navigation
Runtime finalization assumes all other threads have exited. #80657
Description
| BPO | 36476 |
|---|---|
| Nosy | @tim-one, @ncoghlan, @pitrou, @vstinner, @ericsnowcurrently, @phmc, @pablogsal, @nanjekyejoannah |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2019-03-29.20:38:26.289>
labels = ['expert-subinterpreters', 'interpreter-core', 'type-bug', '3.8', '3.9']
title = 'Runtime finalization assumes all other threads have exited.'
updated_at = <Date 2020-06-03.16:42:03.692>
user = 'https://github.com/ericsnowcurrently'bugs.python.org fields:
activity = <Date 2020-06-03.16:42:03.692>
actor = 'vstinner'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core', 'Subinterpreters']
creation = <Date 2019-03-29.20:38:26.289>
creator = 'eric.snow'
dependencies = []
files = []
hgrepos = []
issue_num = 36476
keywords = []
message_count = 10.0
messages = ['339143', '339145', '358745', '358747', '358749', '358750', '358751', '358782', '359101', '359103']
nosy_count = 8.0
nosy_names = ['tim.peters', 'ncoghlan', 'pitrou', 'vstinner', 'eric.snow', 'pconnell', 'pablogsal', 'nanjekyejoannah']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue36476'
versions = ['Python 3.8', 'Python 3.9']
Activity
ericsnowcurrently commentedon Mar 29, 2019
Among the first 3 things that happen in Py_FinalizeEx() are, in order:
At that point the only remaining Python threads are:
The next time any of those threads (aside from main) acquire the GIL, we expect that they will exit via a call to PyThread_exit_thread() (caveat: issue bpo-36475). However, we have no guarantee on when that will happen, if ever. Such lingering threads can cause problems, including crashes and deadlock (see issue bpo-36469).
I don't know what else we can do, beyond what we're already doing. Any ideas?
ericsnowcurrently commentedon Mar 29, 2019
FYI, I've opened bpo-36477 to deal with the subinterpreters case.
ericsnowcurrently commentedon Dec 20, 2019
Adding to the list:
ericsnowcurrently commentedon Dec 20, 2019
Problems with lingering threads during/after runtime finalization continue to be a problem. I'm going to use this issue as the focal point for efforts to resolve this.
Related issues:
ericsnowcurrently commentedon Dec 20, 2019
Analysis by @pconnell:
tl;dr daemon threads and external C-API access during/after runtime finalization are causing crashes.
ericsnowcurrently commentedon Dec 20, 2019
To put it another way:
(from bpo-33608#msg358748)
Adding to that list:
ericsnowcurrently commentedon Dec 21, 2019
So I see 3 things to address here:
Possible solutions (starting point for discussion):
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
pitrou commentedon Dec 21, 2019
I think the answer is to document a bit more clearly that they can pose all kinds of problems. Perhaps we could even display a visible warning when people create daemon threads.
We could run the "join non-daemon threads" routine a *second time* after atexit handlers have been called. It probably can't hurt (unless people do silly things?).
This one I don't know how to handle. By construction, a non-Python thread can do anything it wants, and we cannot add guards against this at the beginning of each C API function. I think that when someone calls the C API, we're clearly in the realm of "consenting adults".
ncoghlan commentedon Dec 31, 2019
Perhaps we need a threading.throw() API, similar to the one we have for generators and coroutines?
If we had that, then Py_FinalizeEx() could gain a few new features:
Adding that would require an enhancement to the PendingCall machinery, though, since most pending calls are only processed in the main thread (there's no way to route them to specific child threads).
A simpler alternative would be to have an atomic "terminate_threads" counter in the ceval runtime state that was incremented to 1 to request that SystemExit be raised in daemon threads, and then to 2 to request that SystemExit be raised in all still running threads. When a thread received that request to exit, it would set a new flag in the thread state to indicate it was terminating, and then raise SystemExit. (The thread running Py_FinalizeEx would set that flag in advance so it wasn't affected, and other threads would use it to ensure they only raised SystemExit once). The runtime cost of this would just be another _Py_atomic_load_relaxed call in the eval_breaker branch. (Probably inside
make_pending_calls, so it gets triggered both by the eval_breaker logic, and by explicit calls toPy_MakePendingCalls).ncoghlan commentedon Dec 31, 2019
Thinking about that idea further, I don't think that change would help much, since the relevant operations should already be checking for thread termination when they attempt to reacquire the GIL.
That means what we're missing is:
gpshead commentedon May 26, 2023
related issue: #104690 "Threads started in exit handler are still running after their thread states are destroyed"
and a related PR: #104826 "Disallow thread creation and fork at interpreter finalization"
gpshead commentedon May 26, 2023
related to the above linked issues and ongoing thoughts about how horrible daemon threads are and wishing they didn't exist... I was pondering an if we could inject the equivalent of an uncatchable exception (meaning even bare except: would not handle it) into all daemon and non-python threads via their tstate so that their code would uncerimoniously exit no matter what. That's as close to a SIGKILL for a thread can we can cleanly get. Perhaps this only makes sense to do after Nick's idea of a SystemExit in the threads and waiting a little while.
ericsnowcurrently commentedon May 27, 2023
You mean in addition to the trick we do in ceval_gil.c, with
tstate_must_exit()andPyThread_exit_thread()?gpshead commentedon May 28, 2023
PyThread_exit_thread()is being deprecated by #28525 as it is impossible to safely end a thread abruptly. So take_gil will turn into an intentional hang in that situation.I was thinking of if we could do something before we get to the point of destroying the thread states - the only safe exit from a thread is for them to actually return all the way up their call stack on their own.