Fix bug 439992 - [win32] KeyboardInterrupt Not Caught.

This gets us closer to consistent Ctrl+C behaviour on NT and Win9x.  NT now reliably generates KeyboardInterrupt exceptions for NT when a file IO operation was aborted.  Bugfix candidate

1 files changed, 33 insertions, 0 deletions

diff --git a/Parser/myreadline.c b/Parser/myreadline.c
index 10e39e5..8fe25ec 100644
--- a/Parser/myreadline.c
+++ b/Parser/myreadline.c
@@ -10,6 +10,10 @@
 */
 
 #include "Python.h"
+#ifdef MS_WINDOWS
+#define WIN32_LEAN_AND_MEAN
+#include "windows.h"
+#endif /* MS_WINDOWS */
 
 int (*PyOS_InputHook)(void) = NULL;
 
@@ -31,6 +35,35 @@ my_fgets(char *buf, int len, FILE *fp)
 		p = fgets(buf, len, fp);
 		if (p != NULL)
 			return 0; /* No error */
+#ifdef MS_WINDOWS
+		/* In the case of a Ctrl+C or some other external event 
+		   interrupting the operation:
+		   Win2k/NT: ERROR_OPERATION_ABORTED is the most recent Win32 
+		   error code (and feof() returns TRUE).
+		   Win9x: Ctrl+C seems to have no effect on fgets() returning
+		   early - the signal handler is called, but the fgets()
+		   only returns "normally" (ie, when Enter hit or feof())
+		*/
+		if (GetLastError()==ERROR_OPERATION_ABORTED) {
+			/* Signals come asynchronously, so we sleep a brief 
+			   moment before checking if the handler has been 
+			   triggered (we cant just return 1 before the 
+			   signal handler has been called, as the later 
+			   signal may be treated as a separate interrupt).
+			*/
+			Sleep(1);
+			if (PyOS_InterruptOccurred()) {
+				return 1; /* Interrupt */
+			}
+			/* Either the sleep wasn't long enough (need a
+			   short loop retrying?) or not interrupted at all
+			   (in which case we should revisit the whole thing!)
+			   Logging some warning would be nice.  assert is not
+			   viable as under the debugger, the various dialogs
+			   mean the condition is not true.
+			*/
+		}
+#endif /* MS_WINDOWS */
 		if (feof(fp)) {
 			return -1; /* EOF */
 		}