[PATCH] [RFC] Move SetConsoleCtrlHandler calls to async thread

[Hannes Domani <ssbssa@yahoo.de>]

Ctrl-C and Ctrl-Break don't work any more since the async commit, so I've tried
to move the SetConsoleCtrlHandler calls.
Now Ctrl-C seems to work, but Ctrl-Break completely stop both gdb and the
inferior (if new-console is disabled).

I'm not sure what's the proper fix is here, please advise.
---
 gdb/windows-nat.c | 66 ++++++++++++++++++++++++++---------------------
 1 file changed, 37 insertions(+), 29 deletions(-)

diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index 17422e15f80..e1034e48da3 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -209,6 +209,8 @@ static CORE_ADDR cygwin_get_dr (int i);
 static unsigned long cygwin_get_dr6 (void);
 static unsigned long cygwin_get_dr7 (void);
 
+static BOOL WINAPI ctrl_c_handler (DWORD event_type);
+
 /* User options.  */
 static bool new_console = false;
 #ifdef __CYGWIN__
@@ -477,7 +479,37 @@ windows_nat_target::process_thread ()
 	{
 	  if (!m_debug_event_pending)
 	    {
+	      /* If the user presses Ctrl-c while the debugger is waiting
+		 for an event, he expects the debugger to interrupt his
+		 program and to get the prompt back.  There are two
+		 possible situations:
+
+		   - The debugger and the program do not share the console, in
+		     which case the Ctrl-c event only reached the debugger.
+		     In that case, the ctrl_c handler will take care of
+		     interrupting the inferior.  Note that this case is
+		     working starting with Windows XP.  For Windows 2000,
+		     Ctrl-C should be pressed in the inferior console.
+
+		   - The debugger and the program share the same console, in
+		     which case both debugger and inferior will receive the
+		     Ctrl-c event.  In that case the ctrl_c handler will
+		     ignore the event, as the Ctrl-c event generated inside
+		     the inferior will trigger the expected debug event.
+
+		     FIXME: brobecker/2008-05-20: If the inferior receives the
+		     signal first and the delay until GDB receives that signal
+		     is sufficiently long, GDB can sometimes receive the SIGINT
+		     after we have unblocked the CTRL+C handler.  This would
+		     lead to the debugger stopping prematurely while handling
+		     the new-thread event that comes with the handling of the
+		     SIGINT inside the inferior, and then stop again
+		     immediately when the user tries to resume the execution
+		     in the inferior.  This is a classic race that we should
+		     try to fix one day.  */
+	      SetConsoleCtrlHandler (&ctrl_c_handler, TRUE);
 	      wait_for_debug_event (&m_last_debug_event, INFINITE);
+	      SetConsoleCtrlHandler (&ctrl_c_handler, FALSE);
 	      m_debug_event_pending = true;
 	    }
 	  serial_event_set (m_wait_event);
@@ -505,7 +537,11 @@ windows_nat_target::wait_for_debug_event_main_thread (DEBUG_EVENT *event)
 	  serial_event_clear (m_wait_event);
 	}
       else
-	wait_for_debug_event (event, INFINITE);
+	{
+	  SetConsoleCtrlHandler (&ctrl_c_handler, TRUE);
+	  wait_for_debug_event (event, INFINITE);
+	  SetConsoleCtrlHandler (&ctrl_c_handler, FALSE);
+	}
       return false;
     });
 }
@@ -1844,35 +1880,7 @@ windows_nat_target::wait (ptid_t ptid, struct target_waitstatus *ourstatus,
 
   while (1)
     {
-      /* If the user presses Ctrl-c while the debugger is waiting
-	 for an event, he expects the debugger to interrupt his program
-	 and to get the prompt back.  There are two possible situations:
-
-	   - The debugger and the program do not share the console, in
-	     which case the Ctrl-c event only reached the debugger.
-	     In that case, the ctrl_c handler will take care of interrupting
-	     the inferior.  Note that this case is working starting with
-	     Windows XP.  For Windows 2000, Ctrl-C should be pressed in the
-	     inferior console.
-
-	   - The debugger and the program share the same console, in which
-	     case both debugger and inferior will receive the Ctrl-c event.
-	     In that case the ctrl_c handler will ignore the event, as the
-	     Ctrl-c event generated inside the inferior will trigger the
-	     expected debug event.
-
-	     FIXME: brobecker/2008-05-20: If the inferior receives the
-	     signal first and the delay until GDB receives that signal
-	     is sufficiently long, GDB can sometimes receive the SIGINT
-	     after we have unblocked the CTRL+C handler.  This would
-	     lead to the debugger stopping prematurely while handling
-	     the new-thread event that comes with the handling of the SIGINT
-	     inside the inferior, and then stop again immediately when
-	     the user tries to resume the execution in the inferior.
-	     This is a classic race that we should try to fix one day.  */
-      SetConsoleCtrlHandler (&ctrl_c_handler, TRUE);
       ptid_t result = get_windows_debug_event (pid, ourstatus, options);
-      SetConsoleCtrlHandler (&ctrl_c_handler, FALSE);
 
       if (result != null_ptid)
 	{
-- 
2.35.1