FYI, after merging that PR I realized that the COMPUTE_EVAL_BREAKER macro isn't quite right. While the following scenario worked before, now it doesn't:
1. interpreter A: _PyEval_AddPendingCall() causes the global
eval breaker to be set
2. interpreter B: the next pass through the eval loop uses
COMPUTE_EVAL_BREAKER; it has no pending calls so the global
eval breaker is unset
3. interpreter A: the next pass through the eval loop does not
run the pending call because the eval breaker is no longer set
This really isn't a problem because the eval breaker is triggered for the GIL pretty frequently. Furthermore, it won't be a problem once the GIL is per-interpreter (at which point we will switch to a per-interpreter eval breaker).
If it is important enough then I can fix it. I even wrote up a solution. [1] However, I'd rather leave it alone (hence no PR). The alternatives are more complicated and the situation should be relatively short-lived.
FWIW, in addition to the solution I mentioned above, I tried a few other ways:
* have a per-interpreter eval breaker in addition to the global one
* have only a per-interpreter eval breaker (the ultimate objective)
* consolidate the pending calls for every interpreter every time
UNSIGNAL_PENDING_CALLS and UNSIGNAL_ASYNC_EXC are used
However, each has performance penalties while the branch I created does not. I try to be really careful when it comes to the performance of the eval loop. :)
[1] https://github.com/ericsnowcurrently/cpython/tree/eval-breaker-shared |