Re: [RFC] control-c handling on Windows...

[Joel Brobecker <brobecker@adacore.com>]

Hi Chris,

> I think the way this is handled in linux is by resetting the controlling
> process group of the terminal to the pid of the inferior.  On thinking
> about this more, I think it probably makes more sense to bracket the
> call with:
> 
>   SetConsoleCtrlHandler (NULL, TRUE);
>   retval = get_win32_debug_event (pid, ourstatus);
>   SetConsoleCtrlHandler (NULL, FALSE);
> 
> That's almost equivalent to what linux does with process groups I think.
> 
> Does the above work in your scenario, Joel?  If so, I think this is
> safe to check in.

I think it does work. All my experiments at resuming the inferior after
having interrupted it with C-c have been succesful.

The only problem is that once in a while GDB still receives the SIGINT.
This time, it doesn't cause the debugger to QUIT during the resume after
handling the new-thread event like it used to, so we properly report the
SIGINT event to the user:

    (gdb) cont
    Continuing.
    I = 10
    I = 11
    I = 12
    [New thread 2348.0x1550]  <<<---  pressed C-c
    
    Program received signal SIGINT, Interrupt.
    [Switching to thread 2348.0x1550]
    0x7c87534d in KERNEL32!GetConsoleCharType (Quit (expect signal SIGINT when the program is resumed)

However, because the SIGINT handler was called, we still get the unexpected
"Quit (expect signal SIGINT when the program is resumed" message in
the middle of printing the current frame. As I said earlier, it doesn't
prevent the next resume to work properly. It's a little misleading but
I think this is already a good improvement, so I suggest we go with your
suggestion.

If only I understood signals and terminals better, I would try to
understand the reason why GDB still gets the SIGINT despite all our
efforts. But, right now, I'm a little in the dark :(. I know that
Nicolas Roche, one of the engineers at AdaCore, has spent quite
a bit of time studying this sort of issues, so I'll see if I can
nudge him a little out of his busy schedule to share some of the ideas
he had.

-- 
Joel