Re: RFC: MI output during program execution

[Bob Rossi <bob@brasko.net>]

On Tue, Aug 09, 2005 at 08:41:28PM -0400, Daniel Jacobowitz wrote:
> On Tue, Aug 09, 2005 at 06:34:21PM -0400, Bob Rossi wrote:
> > However, in the meantime, I think it's possible to query the state of
> > GDB at any moment. So, if you allow the user to enter a command via
> > -interpreter-exec console, you could then follow that command up with
> > other MI commands to sync the state of GDB with the state of the FE.
> 
> But we haven't got all the relevant query commands, I think.  And I
> haven't a clue what the full set would be.  Rather than adding them,
> investing effort in getting the async approach going makes more sense
> to me.

I agree. However, getting the observer approach up and running, will in
a way, define the full set.

> As Jim's pointed out, you can need this any time you hit a breakpoint,
> if the user has set commands on it.  Keeping track of this in the FE is
> going to be tricky.  Also, if you're presenting a real console window
> and you have to do a half-dozen queries after every command to keep the
> UI up to date, that's probably going to be visibly slow.

Here is another odd scenario, Jim, please give some info if you have
experience in this area.

If you hit a breakpoint, and the observer starts to send you data, does
it 
   - send all the state data in one async response, in the same response as
     the async MI command that says *stopped?
   - send all the state data in one async response, in a different response 
     as the async MI command that says *stopped?
   - send all the state data, each in different async response's, in a 
     different response as the async MI command that says *stopped?

This may seem unimportant, however I believe it could be marginally
important. For instance, does the front end have to wait for the async
observer response before it can do anything else?

Thanks,
Bob Rossi