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 <rep...@bugs.python.org>
<http://bugs.python.org/issue18040>
_______________________________________
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;
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
