From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19119 invoked by alias); 7 May 2006 22:01:50 -0000 Received: (qmail 19110 invoked by uid 22791); 7 May 2006 22:01:49 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sun, 07 May 2006 22:01:47 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FcrJx-00050W-C6; Sun, 07 May 2006 18:01:45 -0400 Date: Sun, 07 May 2006 22:50:00 -0000 From: Daniel Jacobowitz To: Bjarke Viksoe Cc: gdb@sourceware.org Subject: Re: asynchronous MI output commands Message-ID: <20060507220145.GA19231@nevyn.them.org> Mail-Followup-To: Bjarke Viksoe , gdb@sourceware.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i 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/msg00069.txt.bz2 On Sun, May 07, 2006 at 11:40:54PM +0200, Bjarke Viksoe wrote: > >Daniel Jacobowitz wrote: > > > >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? > > No, the abstraction layer is exactly my design - but as I explained: the > goal of my tool is that it's used over a remote line (eg. SSH over > internet) where the answer can be a couple of 100ms delayed. It is most > desirable to be able to send multiple commands and have the front-end > digest the answer as they slowly arrive - updating the UI in increments. > Yes, my views need to send multiple -var-evaluate-expression and this is > the reason that I'm forced to restrict the design to what you describe. The > reason it's not good enough: it so slow. > > Because of the latency, my "abstraction layer" runs in its own thread. This > makes the UI wonderfully responsive, but doesn?t allow a component/view to > submit a command and read the answer in the same context. Answers arrive > out of context and are processed separately - creating a high need to know > what the answer originated from. Sorry, but I don't feel like you've answered my question. Why does this interfere with pipelining? Thread A: - gdb_thread.submit_question("-var-evaluate-expression A") Thread B: - gdb_thread.submit_question("-var-evaluate-expression B") GDB thread: - Send "-var-evaluate-expression A". Record this as an outstanding request. - Send "-var-evaluate-expression B". Record this as an outstanding request. - Notice that data is available. - Parse it, and notice that it is a response to a command. Take the first command off the queue of outstanding requests. See that it is -var-evaluate-expression A. Return the answer to that request's submission object, in whatever way you need to. - Notice that more data is available... etc. If this isn't workable, can you fill in the piece I'm missing? Why not? Each command should generate a single synchronous (^done, ^error) response. -- Daniel Jacobowitz CodeSourcery