bpo-40010: Optimize signal handling in multithreaded applications#19067
Merged
vstinner merged 1 commit intopython:masterfrom Mar 19, 2020
vstinner:signal_pending_signals
Merged
bpo-40010: Optimize signal handling in multithreaded applications#19067vstinner merged 1 commit intopython:masterfrom vstinner:signal_pending_signals
vstinner merged 1 commit intopython:masterfrom
vstinner:signal_pending_signals
Conversation
Member
Author
|
I merged PR #19066 which makes https://bugs.python.org/issue40010 worse for subinterpreters if I understand correctly. This PR should make subinterpreter as efficient as they were, or even more efficient, to handle signals. |
aeros
reviewed
Mar 19, 2020
Python/ceval.c
Outdated
Contributor
There was a problem hiding this comment.
The following seems a bit more specifically descriptive of what it's doing, and would make more sense if it's ever used in the future for something other than signal handling:
Suggested change
| thread_can_handle_signals(void) | |
| current_is_main_thread(void) |
Member
Author
There was a problem hiding this comment.
Even if only the main thread of the main interpreter can handle signals, I prefer "thread_can_handle_signals" name to make the function intent more explicit.
Member
Author
test.pythoninfo failed with: test_ttk_guionly failed on Ubuntu: These two errors are unrelated to my PR. |
If a thread different than the main thread gets a signal, the bytecode evaluation loop is no longer interrupted at each bytecode instruction to check for pending signals which cannot be handled. Only the main thread of the main interpreter can handle signals. Previously, the bytecode evaluation loop was interrupted at each instruction until the main thread handles signals. Changes: * COMPUTE_EVAL_BREAKER() and SIGNAL_PENDING_SIGNALS() no longer set eval_breaker to 1 if the current thread cannot handle signals. * take_gil() now always recomputes eval_breaker.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
If a thread gets a signal, the bytecode evaluation loop no longer
tries to handle signals before executing each bytecode instruction,
if the thread must not handle signals.
Previously, it was was done until the main interpreter had the
opportunity to handle signals.
COMPUTE_EVAL_BREAKER() and SIGNAL_PENDING_SIGNALS() no longer set
eval_breaker to 1 if the current thread must not handle signals.
https://bugs.python.org/issue40010