Re: [RFA/RFC] QUIT doesn't seem to be working !?

[Andrew Cagney <cagney@gnu.org>]

Some related history:

non-blocking reads/writes and event loops
http://sources.redhat.com/ml/gdb/2000-06/msg00088.html

remote.c's "async", "extended-async" back ends
http://sources.redhat.com/ml/gdb/2001-02/msg00016.html

remote.c and a re-entrant event-loop
http://sources.redhat.com/ml/gdb/2000-06/msg00144.html

> I think your observations are correct. quit_flag is not set when we
> hit the QUITs, if we use the event loop.  I remember testing the
> behavior of ^-C several times, when I wrote that stuff, but I focused
> more on interrupting a running target (launched with run&, etc) for
> the async remote case. There is even a mechanism in gdb to handle a
> ^-C hit twice.  
> 
> Unfortunately I think that your patch is not completely correct. You
> set up *both* the QUIT machinery and the event-loop to process *one*
> SIGINT the next time through.  Whatever one you reach first, it will
> leave a non-existant event set for the other.
> 
> Probably for the event-loop case we should forget quit_flag and just
> rely on the markers being set in the event-loop machinery. Which means
> that QUIT (or equivalent) will have to figure out if there are any
> high priority events to be processed. Which, if you think about it, is
> like saying that there will be a 'lower-level/inner-level/secondary'
> event loop. In this sigint case, for QUIT to be able to pull out the
> interrupt related markers from the event loop, it means that those
> markers now need to identify themselves somehow. The event loop is
> currently completely agnostic about the kind of events to be
> processed. It only knows that they are generated by a signal (any
> signal), while we want to pull out only the sigint ones. 

Based on the above links.  So this means that QUIT:

#define QUIT { \
   if (quit_flag) quit (); \
   if (interactive_hook) interactive_hook (); \
}

should be replaced by something like:

#define QUIT keep_event_loop_alive ();

> Actually the event loop knows only about 2 kinds (well, 3) kinds of
> events: signals and file-descriptors related events (and timers).  We
> are talking here about subverting that categorization by introducing a
> urgent/high priority kind of event that needs to be processed
> right now, w/o waiting until you get back to the event loop proper.
> 
> So, since 6.1 is approaching, I would mark this as a known problem,
> and try to solve it in mainline, after the branch is cut.

Yes.  I did a quick user poll over lunch and everyone indicated that 
contrl-c "works for me" (the sample included heavy java and C++ users!).

Andrew