From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3198 invoked by alias); 27 Mar 2008 13:25:20 -0000 Received: (qmail 3186 invoked by uid 22791); 27 Mar 2008 13:25:19 -0000 X-Spam-Check-By: sourceware.org Received: from imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 27 Mar 2008 13:24:53 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m2RDOgxN011719; Thu, 27 Mar 2008 08:24:42 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Mar 2008 08:24:41 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Subject: RE: -var-update @ Date: Thu, 27 Mar 2008 13:25:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA04290FD3@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <200803271338.24328.vladimir@codesourcery.com> From: "Marc Khouzam" To: "Vladimir Prus" , "Nick Roberts" Cc: 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: 2008-03/txt/msg00431.txt.bz2 > Incidentally, it seems to be that a really smart frontend might be updati= ng only > those variable objects that a visible on screen. To support this case eff= iciently, > we'd better support >=20 > -var-update var1 var2 var3 ... >=20 > syntax. I'm not proposing such a syntax right now -- we'd need to actuall= y play > with such a smart frontend. DSF only updates varObj that are visible on screen. So currently, it always uses -var-update with a single varObj name (never u= se *). If I understand correctly, > -var-update var1 var2 var3 ... would allow the frontend to update multiple variable objects with a single = command. With the goal of reducing the number of MI commands. Any other benefits? In the case of DSF, we wouldn't be able to use such a command though. The reason is that the views which show the variables are de-coupled from t= he variable object manager; and those views request the value of each variable individually, so the variable manager, which sends -var-update only gets a single varObj request at a time. Not to say that > -var-update var1 var2 var3 ... would not be useful to other "really smart frontends" :-) And, who knows, it may not be too hard for the DSF views to send batch requ= ests containing all the visible variable objects, someday. Marc