Re: asynchronous MI output commands

[Daniel Jacobowitz <drow@false.org>]

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