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

[Joel Brobecker <brobecker@adacore.com>]

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

Yes, and I'm still not sure how to solve it completely :-(. I double-checked
the cygwin case inside a cygwin window, and things seem to be pretty solid
as soon as the SetConsoleCtrlHandler wrapper is installed. Not sure whether
it's a coincidence or whether it's expected that I wouldn't see that race
with a cygwin window (and in fact, I'm not sure that the cygwin window
is relevant to the experiment either). I did verify it again in the case
of mingw.

So, I suggest we install you patch for now. Hopefully we'll find a way
to get rid of the race condition, but in the meantime, we have something
that makes the situation better.

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

Ah, you're right, that would cause job_control to be set on cygwin,
I think. So that means we would probably want to emulate the __MSDOS__
case for mingw only.

-- 
Joel