STINNER Victor <vstin...@python.org> added the comment:
> SIGNAL_PENDING_CALLS() is called on a Python thread via signal.raise_signal() > or _thread.interrupt_main() / PyErr_SetInterrupt(). If you'd rather keep the > COMPUTE_EVAL_BREAKER() call in that case, the console control-event case can > be distinguished via PyGILState_GetThisThreadState(). It returns NULL if > there's no thread state, i.e. WINAPI TlsGetValue returns NULL. That sounds like a micro-optimization which is not worth it. The code is already quite complicated. I don't think that it's a big deal to call eval_frame_handle_pending() *once* when a signal is received whereas the "current" Python thread cannot handle it. This function is quite simple: when there is no nothing to do, it only reads 3 atomic variable and one tstate attribute. It's cheap. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue42296> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
