-
-
Notifications
You must be signed in to change notification settings - Fork 30.8k
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
bpo-40010: Optimize signal handling in multithreaded applications #19067
Conversation
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. |
@@ -120,14 +120,23 @@ static size_t opcache_global_hits = 0; | |||
static size_t opcache_global_misses = 0; | |||
#endif | |||
|
|||
|
|||
static int | |||
thread_can_handle_signals(void) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
thread_can_handle_signals(void) | |
current_is_main_thread(void) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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.
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