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?