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 eryksun
Recipients Mark.Shannon, eryksun, gvanrossum, paul.moore, serhiy.storchaka, steve.dower, tim.golden, vstinner, zach.ware
Date 2020-11-13.03:45:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Note that this issue only applies to a process that has a single Python thread. With multiple Python threads, the signal handler gets called when the main thread acquires the GIL. 

As far as Windows console-driven SIGINT and SIGBREAK are concerned, C signal_handler() is called on a new thread that the interpreter has never seen before and will never see again. But there's also signal.raise_signal(signal.SIGINT) to consider, executing on a Python thread. Another path to trip_signal() is via _thread.interrupt_main(), i.e. PyErr_SetInterrupt().

_Py_ThreadCanHandleSignals() checks whether the current thread is the main thread in the main interpreter. It gets called to guarantee this condition in multiple places, such as handle_signals() in Python/ceval.c. So the _Py_IsMainThread() call is required. In Windows, maybe the main-thread check could be bypassed in SIGNAL_PENDING_SIGNALS() for a non-Python thread (i.e. no tstate), by directly setting ceval2->eval_breaker instead of calling COMPUTE_EVAL_BREAKER() in this case.
Date User Action Args
2020-11-13 03:45:30eryksunsetrecipients: + eryksun, gvanrossum, paul.moore, vstinner, tim.golden, Mark.Shannon, zach.ware, serhiy.storchaka, steve.dower
2020-11-13 03:45:30eryksunsetmessageid: <>
2020-11-13 03:45:30eryksunlinkissue42296 messages
2020-11-13 03:45:29eryksuncreate