[issue18040] SIGINT catching regression on windows in 2.7

Tim Golden report at bugs.python.org
Sun May 26 12:43:37 CEST 2013


Tim Golden added the comment:

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.

----------
keywords: +patch
Added file: http://bugs.python.org/file30382/signalmodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18040>
_______________________________________
-------------- next part --------------
diff --git a/Modules/signalmodule.c b/Modules/signalmodule.c
--- a/Modules/signalmodule.c
+++ b/Modules/signalmodule.c
@@ -974,7 +974,6 @@
         if (PyThread_get_thread_ident() != main_thread)
             return 0;
 #endif
-        Handlers[SIGINT].tripped = 0;
         return 1;
     }
     return 0;


More information about the Python-bugs-list mailing list