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, paul.moore, serhiy.storchaka, steve.dower, tim.golden, vstinner, zach.ware
Date 2020-11-13.12:38:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
This issue reminds me bpo-40082 where I wrote: "The problem on Windows is that each CTRL+c is executed in a different thread." I fixed the issue with:

New changeset b54a99d6432de93de85be2b42a63774f8b4581a0 by Victor Stinner in branch 'master':
bpo-40082: trip_signal() uses the main interpreter (GH-19441)

"Fix the signal handler: it now always uses the main interpreter,
rather than trying to get the current Python thread state."

Here we have to be careful. If _Py_ThreadCanHandleSignals() always return true, we may reintroduce bpo-40010 issue: ceval bytecode evaluation loop may be interrupted at every single instruction and call eval_frame_handle_pending() which does nothing.

COMPUTE_EVAL_BREAKER() decides if the loop must be interrupted.

Rather than modifying _Py_ThreadCanHandleSignals(), I would prefer to modify SIGNAL_PENDING_CALLS(). For example, rather than using COMPUTE_EVAL_BREAKER() complex logic to decide if the current Python thread must check if there is a pending signal, always interrupt and let the thread decide if it has something to do.

The second problem is to reset eval_breaker to 0. If there is no pending signal and no pending call, eval_frame_handle_pending() leaves eval_breaker unchanged. eval_frame_handle_pending() should also be updated to reset eval_breaker in this case.
Date User Action Args
2020-11-13 12:38:41vstinnersetrecipients: + vstinner, gvanrossum, paul.moore, tim.golden, Mark.Shannon, zach.ware, serhiy.storchaka, eryksun, steve.dower
2020-11-13 12:38:41vstinnersetmessageid: <>
2020-11-13 12:38:41vstinnerlinkissue42296 messages
2020-11-13 12:38:40vstinnercreate