From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30582 invoked by alias); 17 Sep 2009 13:51:22 -0000 Received: (qmail 30572 invoked by uid 22791); 17 Sep 2009 13:51:20 -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 imr2.ericy.com (HELO imr2.ericy.com) (198.24.6.3) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 17 Sep 2009 13:51:12 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n8HDmcWE031130; Thu, 17 Sep 2009 08:48:41 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 08:48:34 -0500 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 08:48:33 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 17 Sep 2009 09:48:33 -0400 From: Marc Khouzam To: "'Joel Brobecker'" , "'Tom Tromey'" CC: "'gdb-patches@sourceware.org'" Date: Thu, 17 Sep 2009 13:51:00 -0000 Subject: RE: Another proposal for frontends and queries. Message-ID: References: <20090916214051.GF8910@adacore.com> In-Reply-To: <20090916214051.GF8910@adacore.com> 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/msg00562.txt.bz2 =20 > -----Original Message----- > From: gdb-patches-owner@sourceware.org=20 > [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Joel Brobecker > Sent: Wednesday, September 16, 2009 5:41 PM > To: Tom Tromey > Cc: Marc Khouzam; gdb-patches@sourceware.org > Subject: Re: Another proposal for frontends and queries. >=20 > > One idea from the user 'heinz' (sorry, I don't know your=20 > real name!) was > > to have a query in MI mode throw a specific error, then let=20 > the front > > end reissue the command with the correct response. This is interesting. Maybe there could even be a "^query" answer. The tokenId could be used to label this new MI query. One extra advantage is that an MI query will no longer block GDB. Other MI commands could be accepted while leaving the queried command "on hold". With this, the frontend could choose to query the user or not, without having GDB blocked during the operation. I like this. One worry I have is what will GDB do if the frontend does not answer the query? I guess it can leave the command in the "query queue" for ever, probably won't hurt. > this assumes > that we don't perform any action if an error is thrown. Otherwise, the > user sends the command, receives the query, cancels the command, and > thinks nothing happen. I believe this is what you meant Joel, but just to be sure: for this to work, a query has to happen before any effect of the command is applied. If a command starts doing some work and then queries, then GDB might be in an inconsistent state. But this probably does not happen with the existing queries... it sounds too dangerous. > I've often let the best be the enemy of good, though. It seems like > an acceptable restriction in the way we implement commands,=20 > particularly > since it allows us to avoid potentially complex improvements of > the command architecture. >=20 > That being said, for 7.0, we should just go with the easy and safe > route. That way, existing frontend can work with gdb-7.0, rather > than having to update their code to handle the new approach. Yes, in the case of Eclipse, we wouldn't be able to support this until June 2010. That would be nice addition to MI for a future release. I'm looking forward to making use of it. Marc =20