Author eric.snow
Recipients Johan Dahlin, db3l, emilyemorehouse, eric.snow, koobs, nascheme, ncoghlan, pmpp, serhiy.storchaka, shprotx, steve.dower, vstinner, yselivanov
Date 2019-06-01.23:32:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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

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. :)

Date User Action Args
2019-06-01 23:32:41eric.snowsetrecipients: + eric.snow, nascheme, db3l, ncoghlan, vstinner, pmpp, serhiy.storchaka, yselivanov, koobs, steve.dower, emilyemorehouse, Johan Dahlin, shprotx
2019-06-01 23:32:41eric.snowsetmessageid: <>
2019-06-01 23:32:41eric.snowlinkissue33608 messages
2019-06-01 23:32:40eric.snowcreate