Feature or enhancement
The eval_breaker is a variable that keeps track of requests to break out of the eval loop to handle things like signals, run a garbage collection, or handle asynchronous exceptions. It is currently in the interpreter state (in interp->ceval.eval_breaker). However, some of the events are specific to a given thread. For example, signals and some pending calls can only be executed on the "main" thread of an interpreter.
We should move the eval_breaker to PyThreadState to better handle these thread-specific events. This is more important for the --disable-gil builds where multiple threads within the same interpreter may be running at the same time.
@markshannon suggested a combination of per-interpreter and per-thread state, where the thread copies the per-interpreter eval_breaker state to the per-thread state when it acquires the GIL.
Linked PRs
Reactions are currently unavailable
Feature or enhancement
The eval_breaker is a variable that keeps track of requests to break out of the eval loop to handle things like signals, run a garbage collection, or handle asynchronous exceptions. It is currently in the interpreter state (in interp->ceval.eval_breaker). However, some of the events are specific to a given thread. For example, signals and some pending calls can only be executed on the "main" thread of an interpreter.
We should move the eval_breaker to PyThreadState to better handle these thread-specific events. This is more important for the --disable-gil builds where multiple threads within the same interpreter may be running at the same time.
@markshannon suggested a combination of per-interpreter and per-thread state, where the thread copies the per-interpreter eval_breaker state to the per-thread state when it acquires the GIL.
Linked PRs