From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4120 invoked by alias); 10 May 2006 07:15:36 -0000 Received: (qmail 4098 invoked by uid 22791); 10 May 2006 07:15:31 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 10 May 2006 07:15:25 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Fdiub-0005Ca-9G for gdb@sources.redhat.com; Wed, 10 May 2006 09:15:09 +0200 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 May 2006 09:15:09 +0200 Received: from ghost by zigzag.lvk.cs.msu.su with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 May 2006 09:15:09 +0200 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: asynchronous MI output commands Date: Wed, 10 May 2006 12:43:00 -0000 Message-ID: References: <1147034156.28828.ezmlm@sourceware.org> <20060507211356.GA18033@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.8.2 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00101.txt.bz2 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 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. - Volodya