This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Mark.Shannon, eryksun, gvanrossum, miss-islington, paul.moore, serhiy.storchaka, steve.dower, tim.golden, vstinner, zach.ware
Date 2020-11-13.14:30:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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.
Date User Action Args
2020-11-13 14:30:47vstinnersetrecipients: + vstinner, gvanrossum, paul.moore, tim.golden, Mark.Shannon, zach.ware, serhiy.storchaka, eryksun, steve.dower, miss-islington
2020-11-13 14:30:47vstinnersetmessageid: <>
2020-11-13 14:30:47vstinnerlinkissue42296 messages
2020-11-13 14:30:47vstinnercreate