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

[Christopher Faylor]

On Sat, May 10, 2008 at 11:00:10AM -0700, Joel Brobecker wrote:
>> 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.
>
>I spoke with Nico a little. He is pretty certain, based on what he read
>of the Windows documentation, that we cannot avoid having GDB receive
>the SIGINT. Apparently, the console is responsible for sending those
>signals, and its behavior cannot be changed.
>
>I wonder if there might be some sort of timing issue that causes
>the signal to sometimes be delivered after we stopped ignoring control
>events.  In other words, some of the time, we receive the signal
>reasonably close to when we receive the debug event for the new thread,
>and so it gets ignored.  But some other time, we receive the signal
>sufficiently after we got the debug event that we already got out of
>get_win32_debug_event and restored the regular SIGINT handler...
>That would explain why we're seeing the QUIT message.

i.e., it's a classic race.

>So the problem becomes when to handle the signal and when to ignore it.
>I'll keep thinking about it for a while, but I haven't found a solution
>yet.
>
>On a side note, utils.c:quit is:
>
>    void
>    quit (void)
>    {
>    #ifdef __MSDOS__
>      /* No steenking SIGINT will ever be coming our way when the
>         program is resumed.  Don't lie.  */
>      fatal ("Quit");
>    #else
>      if (job_control
>          /* If there is no terminal switching for this target, then we can't
>             possibly get screwed by the lack of job control.  */
>          || current_target.to_terminal_ours == NULL)
>        fatal ("Quit");
>      else
>        fatal ("Quit (expect signal SIGINT when the program is resumed)");
>    #endif
>    }
>
>Not sure when __MSDOS__ is defined, but perhaps we should extend
>that case to mingw & cygwin as well? At least we wouldn't get the
>"expect signal SIGINT when the program is resumed" part which
>I don't think can happen on Windows anymore.

I'm still assuming that you're talking about mingw here since Cygwin should
have different behavior.  For instance, it implements tcsetpgrp.

cgf