From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18361 invoked by alias); 17 Sep 2009 19:52:39 -0000 Received: (qmail 18353 invoked by uid 22791); 17 Sep 2009 19:52:39 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 17 Sep 2009 19:52:33 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8HJpnWl007492; Thu, 17 Sep 2009 15:51:49 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n8HJpmqq010118; Thu, 17 Sep 2009 15:51:49 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n8HJpl4E032052; Thu, 17 Sep 2009 15:51:48 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 24BFB378204; Thu, 17 Sep 2009 13:51:47 -0600 (MDT) From: Tom Tromey To: Marc Khouzam Cc: "'Joel Brobecker'" , "'gdb-patches\@sourceware.org'" Subject: Re: Another proposal for frontends and queries. References: <20090916214051.GF8910@adacore.com> Reply-To: Tom Tromey Date: Thu, 17 Sep 2009 19:52:00 -0000 In-Reply-To: (Marc Khouzam's message of "Thu, 17 Sep 2009 09:48:30 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00574.txt.bz2 >>>>> "Marc" == Marc Khouzam writes: Marc> This is interesting. Marc> Maybe there could even be a "^query" answer. Marc> The tokenId could be used to label this new MI query. Marc> One extra advantage is that an MI query will no longer block GDB. Marc> Other MI commands could be accepted while leaving the queried Marc> command "on hold". With this, the frontend could choose to query Marc> the user or not, without having GDB blocked during the operation. Marc> I like this. Marc> One worry I have is what will GDB do if the frontend does not answer Marc> the query? I guess it can leave the command in the "query queue" for Marc> ever, probably won't hurt. I think we are talking about different approaches. Having a query "on hold" implies, to me, either a change to use continuation passing style, or that GDB will reenter the event loop from query(). Either of these is certainly doable, but my experience with these approaches (in GUI and CORBA contexts) has been fairly negative. Perhaps I misunderstood what you are saying, though. Instead this idea is to have query() issue a particular kind of error -- and abort the command. Then the MI user could recognize this error, send a special command to stuff some answers into a queue that query() would read, and then restart the command from scratch. There are two assumptions underlying this idea: 1. A command will always ask the same queries in the same order. 2. A command won't commit some change before a query. #1 can be relaxed a little bit, if needed, by having each query report its identity. Then the query queue would actually be a map, associating an identity with an answer. #2 seems like a reasonable assumption. With this approach, GDB would not keep any state when a query fails. It would not need to. Tom