Eric Snow <ericsnowcurren...@gmail.com> added the comment:
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 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33608> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
