Re: [RFC] Inferior stop events

[Elena Zannoni <ezannoni@cygnus.com>]

Hmmm, memory failing... aging process irreversible....
I seem to recall we did something for inferior events notification
Try looking at inferior_event_handler in inf-loop.c.

But yes, the reason for stopping is just spit out directly from
print_stop_reason.  Another thing to keep in mind is that MI was
designed from the start using an async remote target. That had
definitely an influence on how we did things. Remember the out-of-band
output category?

Elena


Keith Seitz writes:
 > 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
 > 
 >