[RFA/RFC] QUIT doesn't seem to be working !?
Andrew Cagney
cagney@gnu.org
Fri Feb 20 16:14:00 GMT 2004
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
More information about the Gdb-patches
mailing list