From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9118 invoked by alias); 7 May 2006 22:50:13 -0000 Received: (qmail 9109 invoked by uid 22791); 7 May 2006 22:50:13 -0000 X-Spam-Check-By: sourceware.org Received: from bay111-f32.bay111.hotmail.com (HELO hotmail.com) (64.4.17.42) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 07 May 2006 22:50:06 +0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 7 May 2006 15:50:04 -0700 Message-ID: Received: from 64.4.17.200 by by111fd.bay111.hotmail.msn.com with HTTP; Sun, 07 May 2006 22:50:03 GMT X-Sender: bviksoe@hotmail.com In-Reply-To: <20060507220145.GA19231@nevyn.them.org> From: "Bjarke Viksoe" To: gdb@sourceware.org Bcc: Subject: Re: asynchronous MI output commands Date: Mon, 08 May 2006 00:36:00 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed 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/msg00071.txt.bz2 > > > > > >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? > > ... > > > > > > 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. > Right. When I was testing all this I ran into more trouble. I would actually see something like this: (gdb) -var-evaluate-expression A ^done,value="12-var-evaluate-expression A 34" (gdb) ^done,value="1234" ...because of the lack of flow-control in the telnet/SSH session (notice how the next command is embedded in the output of the first). This put me back to square#1 since there was now no 1:1 relationship between cmd/answ. While I agree that your plan is workable, I just concluded that keeping track of a command-list wasn't a reliable option without some severe pain when recovery was needed (aka back to the option) - and I didn't feel that I was getting any closer to having a state-less component. I would expect that some front-ends (GUI based ones) will employ a similar design as mine - even if they are in an environment more attached to their GDB - since we've already seen that fireing a backtrace-type command for every step can be very slow and would block the UI unreasonably if not batched in a thread other than the main GUI one. My take was that I assumed that the output was more detailed simply because it would make my life easier in handling the returned output - instead of having to build complex schemes just to call a simple GDB command. bjarke