From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Seitz To: Andrew Cagney Cc: , insight Subject: Re: [RFC] Inferior stop events Date: Fri, 15 Jun 2001 07:38:00 -0000 Message-id: References: <3B297B72.2050409@cygnus.com> X-SW-Source: 2001-06/msg00140.html 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