classification
Title: SIGINT catching regression on windows in 2.7
Type: Stage: resolved
Components: Versions: Python 2.7
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: tim.golden Nosy List: David.Gilman, Gabi.Davar, loewis, sbt, tim.golden
Priority: low Keywords: patch

Created on 2013-05-23 03:01 by David.Gilman, last changed 2013-10-01 09:43 by Gabi.Davar. This issue is now closed.

Files
File name Uploaded Description Edit
issue18040.py tim.golden, 2013-05-25 20:30
signalmodule.patch tim.golden, 2013-05-26 10:43
Messages (7)
msg189843 - (view) Author: David Gilman (David.Gilman) Date: 2013-05-23 03:01
I opened this StackOverflow bug with an example simplified testcase.  As you can see in the first comment a user added that this code worked under Python 2.6 on Windows and no longer works on 2.7.

http://stackoverflow.com/questions/16686510/how-do-i-capture-sigint-in-python-on-windows?noredirect=1#comment24013681_16686510

Here's a patch that went into the 2.7 release that maybe is related? http://bugs.python.org/issue1677
msg189996 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2013-05-25 20:30
My initial reaction is that, whether the 2.7 behaviour is faulty or not, I can't reproduce the "correct" behaviour on any version of Windows going back to 2.4. Take the attached Python file issue18040.py and run "c:\pythonxx\python.exe -i issue18040.py" for any version of Python from 2.4 to 3.4. At the interpreter prompt, pressing Ctrl-C produces "Keyboard Interrupt" consistently (except for the few times it exits the interpreter which is the problem fixed in issue1677).

Note that this applies to pressing Ctrl-C *at the interpreter prompt* (while the running code is the function my_fgets in parser/myreadline.c). Pressing Ctrl-C in other circumstances, eg in the middle of a long-running os.walk or a time.sleep, invokes the signal handler as expected.

I don't know if the handler *should* be invoked at the interpreter prompt. I recognise that it does so under Linux, but are there any circumstances where that would actually be useful?
msg190072 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2013-05-26 10:43
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.
msg190349 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2013-05-30 08:32
Personally, I'm +0 at best on this change. It would achieve consistency with Linux but I'm not sure what you'd do with such functionality.

Adding Richard Oudkerk who did the rework of the interrupt signal for 3.3. Richard, any opinion on this?
msg190353 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2013-05-30 10:54
I am not to familiar with the signal handling machinery.  (I only did 
some refactoring to expose the event handle already used by time.sleep().)

The change looks reasonable, but I am also not sure how necessary it is.
msg190371 - (view) Author: David Gilman (David.Gilman) Date: 2013-05-30 16:35
So the original motivation here was to piggyback on SIGINT in order to do something like this on Windows: http://stackoverflow.com/questions/132058/showing-the-stack-trace-from-a-running-python-application

I've given Tim's patch a shot and I see that I've been barking up the wrong tree.  I agree that this one-liner is a kinda invasive change and probably isn't worth putting in a point release.  Thanks for the help.
msg190373 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2013-05-30 17:44
Thanks for the feedback, David. Closing as won't fix.
History
Date User Action Args
2013-10-01 09:43:29Gabi.Davarsetnosy: + Gabi.Davar
2013-05-30 17:44:16tim.goldensetstatus: open -> closed
resolution: wont fix
messages: + msg190373

stage: patch review -> resolved
2013-05-30 16:35:41David.Gilmansetmessages: + msg190371
2013-05-30 10:54:15sbtsetmessages: + msg190353
2013-05-30 08:32:22tim.goldensetpriority: normal -> low

nosy: + sbt
messages: + msg190349

stage: patch review
2013-05-26 10:43:37tim.goldensetfiles: + signalmodule.patch
keywords: + patch
messages: + msg190072
2013-05-25 20:30:38tim.goldensetfiles: + issue18040.py
assignee: tim.golden
messages: + msg189996
2013-05-24 09:55:34loewissetnosy: + loewis, tim.golden
2013-05-23 03:01:06David.Gilmancreate