This is the mail archive of the
insight@sources.redhat.com
mailing list for the Insight project.
Re: [RFC] Inferior stop events
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: [RFC] Inferior stop events
- From: Keith Seitz <keiths at cygnus dot com>
- Date: Fri, 15 Jun 2001 07:38:51 -0700 (PDT)
- cc: <gdb at sources dot redhat dot com>, insight <insight at sources dot redhat dot com>
On Thu, 14 Jun 2001, Andrew Cagney wrote:
> I think everyone agreed this was wrong long ago. It should be:
>
>
> GDB Internals -> message -> Insight
> | |
> -------- Event Loop ---------
>
>
> That is, instead of Insight sitting on top of GDB processing stuff
> instantly, Insight would sit adjacent to GDB, allow GDB to complete its
> processing and *then* start processing any events it has outstanding.
This is exactly what I have proposed. All of gdb-events.sh's "events" can
act as either hooks or real, queued events. Right now I am using them as
hooks, but it has always been my plan to export those events into the Tk
event loop.
> In such a model, I don't think any (or very few) hooks are needed.
> Insight can find out the stop reason by asking GDB (just like MI did).
> All GDB needs to do is tell insight that the program state changed.
That is correct. I've been whacking all the hooks and inserting event
notifications.
I cannot find where mi asks for state information, could you point it out?
As far as I can tell, MI relies on some annotated output from
print_stop_reason.
I'll keep looking for the MI implementation of this...
Keith