From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26277 invoked by alias); 18 Sep 2009 14:57:07 -0000 Received: (qmail 26268 invoked by uid 22791); 18 Sep 2009 14:57:06 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 Sep 2009 14:57:00 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n8IEu0hb005461; Fri, 18 Sep 2009 09:56:03 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Sep 2009 09:55:31 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Sep 2009 09:55:30 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 18 Sep 2009 10:55:30 -0400 From: Marc Khouzam To: "'Tom Tromey'" CC: "'Joel Brobecker'" , "'gdb-patches@sourceware.org'" Date: Fri, 18 Sep 2009 14:57:00 -0000 Subject: RE: Another proposal for frontends and queries. Message-ID: References: <20090916214051.GF8910@adacore.com> In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes 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/msg00595.txt.bz2 > -----Original Message----- > From: Tom Tromey [mailto:tromey@redhat.com]=20 > Sent: Thursday, September 17, 2009 3:52 PM > To: Marc Khouzam > Cc: 'Joel Brobecker'; 'gdb-patches@sourceware.org' > Subject: Re: Another proposal for frontends and queries. >=20 > >>>>> "Marc" =3D=3D Marc Khouzam writes: >=20 > 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. >=20 > Marc> One extra advantage is that an MI query will no longer=20 > block GDB. > Marc> Other MI commands could be accepted while leaving the queried > Marc> command "on hold". With this, the frontend could=20 > choose to query > Marc> the user or not, without having GDB blocked during the=20 > operation. > Marc> I like this. >=20 > Marc> One worry I have is what will GDB do if the frontend=20 > does not answer > Marc> the query? I guess it can leave the command in the=20 > "query queue" for > Marc> ever, probably won't hurt. >=20 > I think we are talking about different approaches. >=20 > Having a query "on hold" implies, to me, either a change to use > continuation passing style, or that GDB will reenter the=20 > event loop from > query(). >=20 > Either of these is certainly doable, but my experience with these > approaches (in GUI and CORBA contexts) has been fairly negative. >=20 > Perhaps I misunderstood what you are saying, though. Nope, you got it right. But now I see that was not the proposal. > Instead this idea is to have query() issue a particular kind=20 > of error -- > and abort the command. >=20 > 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. Ok, now I see. I didn't realize the command would be restarted from scratc= h. Thanks for the explanation. And that is a better solution. Although I a b= it concerned about an infinite loop between the FE and GDB, if things are not handled properly by the FE. > There are two assumptions underlying this idea: >=20 > 1. A command will always ask the same queries in the same order. > 2. A command won't commit some change before a query. >=20 > #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,=20 > associating > an identity with an answer. >=20 > #2 seems like a reasonable assumption. >=20 > With this approach, GDB would not keep any state when a query fails. > It would not need to. This makes sense. The last (I think :-)) part that I don't understand is if a FE must code in advance for a potential query? This solution seems to go towards a way that would allow a FE to be ready for any query on any command. A new query could be added to a command by a new GDB version, and FEs would not need to change. That would be nice.=20=20 Is that how you see it? I'm asking because, in some case a FE will want to answer the query itself, without seeking input from the user. For example, for PRecord, when the query asks if we should allow to change memory, I won't ask the user, I just want to say 'y'. I don't see how a FE could be smart enough to generically answer queries like that? (unless we code for it in advance) On the flip side, if a FE knows in advance the potential queries to a specific command, then maybe all we need is some new MI general parameter "-query " that could be added by the frontend to any command (some details would need to be worked out to handle multiple queries in the same command though). Does this make sense? Thanks Marc