From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19226 invoked by alias); 10 May 2006 18:48:05 -0000 Received: (qmail 19217 invoked by uid 22791); 10 May 2006 18:48:04 -0000 X-Spam-Check-By: sourceware.org Received: from qnxmail.qnx.com (HELO nimbus.ott.qnx.com) (209.226.137.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 10 May 2006 18:47:53 +0000 Received: by nimbus.ott.qnx.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 May 2006 14:47:50 -0400 Message-ID: <3518719F06577C4F85DA618E3C37AB9105359CCA@nimbus.ott.qnx.com> From: Alain Magloire To: Vladimir Prus , gdb@sources.redhat.com Subject: RE: asynchronous MI output commands Date: Wed, 10 May 2006 22:15:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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/msg00113.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. > 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.