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

[Joel Brobecker <brobecker@adacore.com>]

> 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.

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.

-- 
Joel