| 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) *  |
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 .py and run "c:\pythonxx\python.exe -i .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 ). 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) * |
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) * |
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) * |
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) * |
Date: 2013-05-30 17:44 |
| Thanks for the feedback, David. Closing as won't fix. |
|
|