Issue #1677: Handle better a race condition between the interactive interpreter and

the Ctrl-C signal handler on Windows

Parser/myreadline.c

@@ -35,6 +35,9 @@ int (*PyOS_InputHook)(void) = NULL;
 static int
 my_fgets(char *buf, int len, FILE *fp)
 {
+#ifdef MS_WINDOWS
+    HANDLE hInterruptEvent;
+#endif
     char *p;
     int err;
     while (1) {
@@ -50,32 +53,28 @@ my_fgets(char *buf, int len, FILE *fp)
             return 0; /* No error */
         err = errno;
 #ifdef MS_WINDOWS
-        /* In the case of a Ctrl+C or some other external event
+        /* Ctrl-C anywhere on the line or Ctrl-Z if the only character
-           interrupting the operation:
+           on a line will set ERROR_OPERATION_ABORTED. Under normal
-           Win2k/NT: ERROR_OPERATION_ABORTED is the most recent Win32
+           circumstances Ctrl-C will also have caused the SIGINT handler
-           error code (and feof() returns TRUE).
+           to fire which will have set the event object returned by
-           Win9x: Ctrl+C seems to have no effect on fgets() returning
+           _PyOS_SigintEvent. This signal fires in another thread and
-           early - the signal handler is called, but the fgets()
+           is not guaranteed to have occurred before this point in the
-           only returns "normally" (ie, when Enter hit or feof())
+           code.
+
+           Therefore: check whether the event is set with a small timeout.
+           If it is, assume this is a Ctrl-C and reset the event. If it
+           isn't set assume that this is a Ctrl-Z on its own and drop
+           through to check for EOF.
         */
         if (GetLastError()==ERROR_OPERATION_ABORTED) {
-            /* Signals come asynchronously, so we sleep a brief
+            hInterruptEvent = _PyOS_SigintEvent();
-               moment before checking if the handler has been
+            switch (WaitForSingleObject(hInterruptEvent, 10)) {
-               triggered (we cant just return 1 before the
+            case WAIT_OBJECT_0:
-               signal handler has been called, as the later
+                ResetEvent(hInterruptEvent);
-               signal may be treated as a separate interrupt).
-            */
-            Sleep(1);
-            if (PyOS_InterruptOccurred()) {
                 return 1; /* Interrupt */
+            case WAIT_FAILED:
+                return -2; /* Error */
             }
-            /* 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)) {
@@ -94,7 +93,7 @@ my_fgets(char *buf, int len, FILE *fp)
 #endif
             if (s < 0)
                     return 1;
-	    /* try again */
+        /* try again */
             continue;
         }
 #endif