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 tim.golden
Recipients David.Gilman, loewis, tim.golden
Date 2013-05-26.10:43:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <51A1E754.3070309@timgolden.me.uk>
In-reply-to <1369513838.33.0.115378342996.issue18040@psf.upfronthosting.co.za>
Content
Correction: I see the desired behaviour in 3.3/3.4 which is where the
overhaul to Ctrl-C handling on Windows was applied. I still can't see it
in 2.6 or in 3.1/3.2 on Windows.

The problem lies in the fact that PyOS_InterruptOccurred and 
PyErr_CheckSignals from signalmodule.c both check and reset signalled 
events. The former is used (solely within myreadline.c) to determine 
whether a SIGINT has fired; the latter is called in many different 
places to initiate Python's signal-handling but doesn't return any 
information about which signal fired.

The check in line 70 of Parser/myreadline.c determines that a SIGINT 
signal has fired, but clears that signal at the same time. Any later 
call to PyErr_CheckSignals will not see that the SIGINT had fired.

The 3.3+ situation is different, as a Windows event is the indication 
that SIGINT was raised, and the check for this doesn't affect the 
internal Handlers table which is examined by PyErr_CheckSignals.

The attached patch to signalmodule.c appears to produce SIGINT signal 
handling as desired. Tested only on Windows. It's not clear whether any 
unittest could be produced for this kind of functionality.
Files
File name Uploaded
signalmodule.patch tim.golden, 2013-05-26.10:43:36
History
Date User Action Args
2013-05-26 10:43:37tim.goldensetrecipients: + tim.golden, loewis, David.Gilman
2013-05-26 10:43:37tim.goldenlinkissue18040 messages
2013-05-26 10:43:36tim.goldencreate