@@ -70,7 +70,8 @@ COMPUTE_EVAL_BREAKER(PyInterpreterState *interp,
7070 && _Py_ThreadCanHandleSignals (interp ))
7171 | (_Py_atomic_load_relaxed_int32 (& ceval2 -> pending .calls_to_do )
7272 && _Py_ThreadCanHandlePendingCalls ())
73- | ceval2 -> pending .async_exc );
73+ | ceval2 -> pending .async_exc
74+ | _Py_atomic_load_relaxed_int32 (& ceval2 -> gc_scheduled ));
7475}
7576
7677
@@ -945,6 +946,7 @@ _Py_HandlePending(PyThreadState *tstate)
945946 if (_Py_atomic_load_relaxed_int32 (& interp_ceval_state -> gc_scheduled )) {
946947 _Py_atomic_store_relaxed (& interp_ceval_state -> gc_scheduled , 0 );
947948 _Py_RunGC (tstate );
949+ COMPUTE_EVAL_BREAKER (tstate -> interp , ceval , interp_ceval_state );
948950 }
949951
950952 /* Pending signals */
@@ -988,16 +990,17 @@ _Py_HandlePending(PyThreadState *tstate)
988990 return -1 ;
989991 }
990992
991- #ifdef MS_WINDOWS
992- // bpo-42296: On Windows, _PyEval_SignalReceived() can be called in a
993- // different thread than the Python thread, in which case
993+
994+ // It is possible that some of the conditions that trigger the eval breaker
995+ // are called in a different thread than the Python thread. An example of
996+ // this is bpo-42296: On Windows, _PyEval_SignalReceived() can be called in
997+ // a different thread than the Python thread, in which case
994998 // _Py_ThreadCanHandleSignals() is wrong. Recompute eval_breaker in the
995999 // current Python thread with the correct _Py_ThreadCanHandleSignals()
9961000 // value. It prevents to interrupt the eval loop at every instruction if
9971001 // the current Python thread cannot handle signals (if
9981002 // _Py_ThreadCanHandleSignals() is false).
9991003 COMPUTE_EVAL_BREAKER (tstate -> interp , ceval , interp_ceval_state );
1000- #endif
10011004
10021005 return 0 ;
10031006}
0 commit comments