New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
atexit callbacks should be run at subinterpreter shutdown #76082
Comments
What is the expected behavior here? |
Hmm, I don't think calling Py_Finalize in any interpreter other than the main one is actually defined at all, so I'm inclined to just make it an error, rather than trying to figure out how it should work. It would then be up to the embedding application to make sure it switched back to the main interpreter before calling Py_Finalize. (We don't have this concern with Py_Initialize, since that *creates* the main interpreter) |
For the main interpreter, Py_Finalize should be destroying all other subinterpreters as one of the first things it does, so if we're *not* currently doing that, it would make sense to fix it as part of Eric's subinterpreters PEP. |
I don't have a reason to think Py_Finalize is not *destroying* the other subinterpreters. But it's not calling their atexit callbacks. (Is there any reason Py_Finalize couldn't switch to the main interpreter itself? Assuming it's even necessary.) |
I guess we allow an unhandled SystemExit in a child thread to propagate to (and hence terminate) the main thread, so allowing a Py_Finalize call in a subinterpreter to terminate the main interpreter would be comparable to that. My main rationale for *requiring* that the main interpreter be active (or be made active) when shutting down is to reduce the number of scenarios we need to test (right now we only test Py_Initialize/Py_Finalize cycles with a single interpreter, and officially allowing finalization from arbitrary interpreters expands that test matrix a fair bit). |
I'm not sure where the concept of "main subinterpreter" comes in, with respect to this issue. I thnik the issue of atexit callbacks could be solved by something like keeping info about each callback's subinterpreter, and switching subinterpreters before running each one. I can see the locking needed for that being quite hairy, but independent of which thread calls all this. |
When you destroy a subinterpreter before Py_Finalize is called, Python can't start calling its atexit callbacks – they no longer have a subinterpreter to run in. Therefore I think callbacks for a particular subinterpreter should be called when (and only when) that subinterpreter is destroyed. Regardless of whether it's the main one or not. |
FWIW, that atexit callbacks were not called for sub interpreters ever was a pain point for mod_wsgi. What mod_wsgi does is override the destruction sequence so that it will first go through each sub interpreter when and shutdown threading explicitly, then call atexit handlers. When that is done, only then will it destroy the sub interpreter and the main interpreter. I have noted this previously in discussion associated with: |
Ah, I see - yeah, that makes a lot of sense. I've retitled the issue to make it clearer that the problem is where the responsibility for calling atexit functions lives - currently it's in Py_Finalize, but really it should be inside the interpreter object's own teardown code. |
I created a PR with fix on this issue - #4611 This makes Py_EndInterpreter() call atexit callbacks for the subinterpreter it is destroying. It doesn't make Py_Finalize() end all subinterpreters, as the current implementation of subinterpreters makes it hard to do so. This is the same as the current behaviour: you need to end all subinterpreters before calling Py_Finalize(). |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: