GeezerVison is showing github.com — bpo-39984: Move pending calls to PyInterpreterState by vstinner · Pull Request #19066 · python/cpython
Conversation
vstinner
commented
Mar 19, 2020
•
edited by bedevere-bot
Loading
Uh oh!
There was an error while loading. Please reload this page.
If Py_AddPendingCall() is called in a subinterpreter, the function is
now scheduled to be called from the subinterpreter, rather than being
called from the main interpreter.
Each subinterpreter now has its own list of scheduled calls.
- Move 'pending 'and 'eval_breaker' fields from _PyRuntimeState.ceval
to PyInterpreterState.ceval.
- new_interpreter() now calls _PyEval_InitThreads() to initialize
pending calls (create the lock on pending calls).
- Fix Py_AddPendingCall() for subinterpreters. It now calls
_PyThreadState_GET() which works in a subinterpreter if the
caller holds the GIL, and only falls back on
PyGILState_GetThisThreadState() if _PyThreadState_GET()
returns NULL.
https://bugs.python.org/issue39984
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
If Py_AddPendingCall() is called in a subinterpreter, the function is
now scheduled to be called from the subinterpreter, rather than being
called from the main interpreter.
Each subinterpreter now has its own list of scheduled calls.
* Move 'pending 'and 'eval_breaker' fields from _PyRuntimeState.ceval
to PyInterpreterState.ceval.
* new_interpreter() now calls _PyEval_InitThreads() to initialize
pending calls (create the lock on pending calls).
* Fix Py_AddPendingCall() for subinterpreters. It now calls
_PyThreadState_GET() which works in a subinterpreter if the
caller holds the GIL, and only falls back on
PyGILState_GetThisThreadState() if _PyThreadState_GET()
returns NULL.
|
If a subinterpreter running in a thread gets a signal, SIGNAL_PENDING_SIGNALS() sets signals_pending to 1 and eval_breaker to 1. In this case, subinterpreter calls handle_signals(), but since it's not the main thread, it does nothing and signals_pending value remains 1.
Later, when the main interpreter will run in the main thread, COMPUTE_EVAL_BREAKER() sets eval_breaker to 1 and so handle_signals() will be called. Finally, signals are handled, and signals_pending is reset to 0.
In short, this PR changes should not break signal handling.
But it's unclear to me what happens with eval_break value when handle_signals() is called in a thread different than the main thread or in a subinterpreter. Will the thread "break" the ceval loop at each instruction to call handle_signals()? Is eval_break value reset to 0? If yes, when?
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Assignees
No one assigned
Milestone
No milestone
Development
Successfully merging this pull request may close these issues.
Uh oh!
There was an error while loading. Please reload this page.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
|