From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3638 invoked by alias); 15 Jun 2008 17:37:45 -0000 Received: (qmail 3628 invoked by uid 22791); 15 Jun 2008 17:37:45 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 15 Jun 2008 17:37:27 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.63) (envelope-from ) id 1K7wAK-00036M-Sr for gdb-patches@sourceware.org; Sun, 15 Jun 2008 21:37:24 +0400 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1K7wA8-000361-Kb; Sun, 15 Jun 2008 21:37:08 +0400 From: Vladimir Prus To: Nick Roberts , Pedro Alves , gdb-patches@sourceware.org Subject: Re: [patch:MI] Observer for thread-changed Date: Sun, 15 Jun 2008 17:58:00 -0000 User-Agent: KMail/1.9.9 References: <18509.7945.19078.399646@kahikatea.snap.net.nz> <200806141909.37719.ghost@cs.msu.su> <20080614191328.GA11666@caradoc.them.org> In-Reply-To: <20080614191328.GA11666@caradoc.them.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200806152137.07276.ghost@cs.msu.su> 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-06/txt/msg00276.txt.bz2 On Saturday 14 June 2008 23:13:28 Daniel Jacobowitz wrote: > On Sat, Jun 14, 2008 at 07:09:37PM +0400, Vladimir Prus wrote: > > I'm afraid you are oversimplifying -- the "the notification is > > emitted whenever the active thread changes" is very nice, but it's very > > likely that every frontend author will not realize he has to ignore this > > notification from -thread-select. So, the documentation should either say > > that the notification is better ignored, or say that is not emitted. Now, what > > is better? > > Seems clear to me: it should be in the example output of > -thread-select, and a reference to there from the description of the > event. Which would nicely eliminate any difference in documentation complexity you originally presented as argument. > > I'd like this notification to communicate, from GDB to frontend, that GDB > > has encountered a command that indicates explicit user desire to change > > the thread he looks at, and that frontend typically should react by making > > that thread selected in UI. > > Wouldn't it make sense to use the same notification if the inferior > stopping causes the selected thread to change, which is how things > work today in all-stop? It would. Why GDB changes the selected thread on stop, in the first place? Presumably, because it thinks that user really want to look at this thread. Then, emitting a notification suggesting that the frontend shows that thread, makes perfect sense. > > In other words, I argue for notification to be designed with the view of > > what frontend is supposed to do with it, not with what internal detail of > > GDB is been reported. > > This is a good principle, but it's not right either. Reporting the > internal state of GDB is bad design, but reporting based on what > frontends are supposed to do is also bad design: it assumes that you > can think of everything a frontend might want to do. We need to > report logical interface events based on GDB's state. Oh, we're in too abstract fields now :-) How are you planning to design logical interface without any consideration what frontend needs, and without necessary limiting what frontend may be able to do? For all new MI features, it's necessary to start with what current frontends need, and build interface as reasonable generalization of that cases. And, each MI interface, especially notifications, *must* come with exact documentation of semantics for frontend. Really, saying that there's current thread and whenever it changes, frontend is notified, does not actually tell frontend enough to accurately handle anything. In light of that, I've started writing a spec about how MI handles threads and frames, including in non-stop mode. I'm gonna post that soonish, and hopefully we'll get more concrete discussion. - Volodya