Uh oh!
There was an error while loading. Please reload this page.
bpo-40010: Optimize signal handling in multithreaded applications - #19067
Conversation
vstinner
commented
Mar 19, 2020
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. |
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:
| thread_can_handle_signals(void) | |
| current_is_main_thread(void) |
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.
vstinner
commented
Mar 19, 2020
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