◐ Shell
clean mode source ↗

Message 344245 - Python tracker

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