Re: RFC: MI output during program execution

[Bob Rossi <bob@brasko.net>]

On Tue, Aug 09, 2005 at 10:59:25AM -0700, Jim Ingham wrote:
> The front end needs to know if a CLI command executed via "- 
> interpreter-exec console" changed the current thread or frame - so it  
> can update the UI accordingly.  Or if it started the target running.   
> Or if it added a breakpoint.
> 
> All these things could be queried from existing commands in the MI,  
> but that's pretty inconvenient and inefficient.  It's much easier to  
> code up the UI if gdb tells it asynchronously about these things.

OK, well then I completly agree that observers would be a very nice way
to solve this problem. When an internal MI state changes, it should
alert the FE if the FE requested such knowledge. This is of course, an
asyncronous approach as far as the FE is concerned. If the FE needs this
information now, it can simply poll GDB for this information.

Also, I'm not convinced it would be inefficient to query GDB for the
required information, especially if a new MI command was added to GDB
that returned the current state of GDB. (frame,thread,file). 

How does -interpreter-exec console work in the case when the user
executes a command, that makes up several other commands?

define mess_with_mi_people
   b main
   r
   n
   n
end

I don't think this case would currently work as expected. Would it?

Thanks,
Bob Rossi