-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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
Inefficient signal handling in multithreaded applications #84191
Comments
When a thread gets a signal, SIGNAL_PENDING_SIGNALS() sets signals_pending to 1 and eval_breaker to 1. In this case, _PyEval_EvalFrameDefault() calls handle_signals(), but since it's not the main thread, it does nothing and signals_pending value remains 1. Moreover, eval_breaker value remains 1 which means that the following code will be called before executing *each* bytecode instruction. if (_Py_atomic_load_relaxed(eval_breaker)) {
(...)
opcode = _Py_OPCODE(*next_instr);
if (opcode == SETUP_FINALLY || ...) {
...
}
if (_Py_atomic_load_relaxed(&ceval->signals_pending)) {
if (handle_signals(tstate) != 0) {
goto error;
}
}
if (_Py_atomic_load_relaxed(&ceval->pending.calls_to_do)) {
...
}
if (_Py_atomic_load_relaxed(&ceval->gil_drop_request)) {
...
}
if (tstate->async_exc != NULL) {
...
}
} This is inefficient. I'm working on a PR modifying SIGNAL_PENDING_SIGNALS() to not set eval_breaker to 1 if the current thread is not the main thread. |
Good catch on this, Victor. Thanks for doing it. |
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: