This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: asynchronous MI output commands
- From: Alain Magloire <alain at qnx dot com>
- To: Vladimir Prus <ghost at cs dot msu dot su>, gdb at sources dot redhat dot com
- Date: Wed, 10 May 2006 14:47:49 -0400
- Subject: RE: asynchronous MI output commands
>
> Daniel Jacobowitz wrote:
>
> > On Sun, May 07, 2006 at 11:09:51PM +0200, Bjarke Viksoe wrote:
> >> In my case I wish to submit several commands at once and slowly digest
> >> the answer (over a remote line where the network round-trip is slow).
> >> Using the <token> is clumsy and doesn't solve the problem of having
> >> enough information to process the answer without keeping track of the
> >> question. Since separate components handle the output autonomously, I
> had
> >> to give up tracking a command-list, and instead had to make sure only 1
> >> question was lingering - thus making the entire solution run much
> slower
> >> than otherwise needed.
> >>
> >> I found that commands that return "^value" result-records (such as
> >> -var-evaluate-expression and -data-evaluate-expression) doesn't carry
> >> enough information. I don't think a model where the entire command is
> >> repeated in the output is a desirable design, but at least identifying
> >> the question-type and its crucial parameters would suffice.
> >
> > If I were writing a front-end, I would have an arbitration layer which
> > sent questions to GDB and received answers. The answers will come back
> > one at a time, in the same order the questions were asked. If you send
> > two -var-evaluate-expression commands, you'll get back two answers, in
> > that same order.
> >
> > Am I missing something? Is there a reason that this isn't enough?
>
> For the record, that's basically what I have in KDevelop. There's command
> queue, and commands are sent to gdb one-at-a-time, and responses come
> exactly in the same order. Remembering the last issued command (i.e.
> instance of GDBCommand class internal to KDevelop) makes it possible to
> route the response back to the original command.
>
> I'm don't quite understand the problems being discussed in this thread.
> It's
> not apparent why one has to know the type of the last command while
> parsing, and if so, why remembering the last command is bad idea.
>
> It's hard to believe that response from MI can be useful without knowing
> the
> last issued command. Say, response from -data-evaluate-expression is
> useless if you don't know what part of frontend wants that data --
> evaluating expression is used in many use cases. So, you need to associate
> extra data with commands anyway.
>
I agree, the example that comes to my mind is "next", "step", "finish",
"continue" etc ... To do some optimization front-ends will probably need to
know the last command issue (for example clearing all the variable state in
a variable view for "continue").
Maybe I'm mistaken but I have the impression, looking at the thread, some
folks are confusing OOB and synchronous response that comes after issuing a
command.
An implementation of MI could be made to be totally asynchronous if all
response could be tag to a matching command. OOB should not be paired to
any commands.