Message344245
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 |
|
Date |
User |
Action |
Args |
2019-06-01 23:32:41 | eric.snow | set | recipients:
+ eric.snow, nascheme, db3l, ncoghlan, vstinner, pmpp, serhiy.storchaka, yselivanov, koobs, steve.dower, emilyemorehouse, Johan Dahlin, shprotx |
2019-06-01 23:32:41 | eric.snow | set | messageid: <1559431961.17.0.639232739651.issue33608@roundup.psfhosted.org> |
2019-06-01 23:32:41 | eric.snow | link | issue33608 messages |
2019-06-01 23:32:40 | eric.snow | create | |
|