bpo-39984: Move pending calls to PyInterpreterState #19066
Conversation
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? |
|
Signal handling is inefficient in multithreaded applications: I created https://bugs.python.org/issue40010 to propose PR #19067 optimization. |
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.
to PyInterpreterState.ceval.
pending calls (create the lock on pending 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