This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: asynchronous MI output commands
- From: Daniel Jacobowitz <drow at false dot org>
- To: gdb at sourceware dot org
- Date: Sun, 7 May 2006 17:13:56 -0400
- Subject: Re: asynchronous MI output commands
- References: <1147034156.28828.ezmlm@sourceware.org> <BAY111-F12EFFA1AB499527B535C56A0AB0@phx.gbl>
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?
--
Daniel Jacobowitz
CodeSourcery