From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32140 invoked by alias); 10 Jun 2008 08:40:36 -0000 Received: (qmail 32127 invoked by uid 22791); 10 Jun 2008 08:40:35 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 10 Jun 2008 08:40:09 +0000 Received: from kahikatea.snap.net.nz (215.60.255.123.dynamic.snap.net.nz [123.255.60.215]) by viper.snap.net.nz (Postfix) with ESMTP id B8F363DA11E; Tue, 10 Jun 2008 20:40:06 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id AF03A8FC6D; Tue, 10 Jun 2008 20:39:50 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18510.15829.135063.624409@kahikatea.snap.net.nz> Date: Tue, 10 Jun 2008 09:24:00 -0000 To: Vladimir Prus Cc: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [patch:MI] Observer for thread-changed In-Reply-To: <200806101027.38454.ghost@cs.msu.su> References: <18509.7945.19078.399646@kahikatea.snap.net.nz> <200806100104.28694.pedro@codesourcery.com> <18509.57602.879804.675918@kahikatea.snap.net.nz> <200806101027.38454.ghost@cs.msu.su> X-Mailer: VM 7.19 under Emacs 22.2.50.2 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-06/txt/msg00194.txt.bz2 > The question, then, if whether -thread-select should output this > notification? Suppose a frontend uses -thread-select to get some data in > some thread without making it selected. Then, if a notification is emitted, > the frontend has to take special care not to mark the thread as selected in > GUI. You could say the same about user-defined functions that use the "threads" command. I don't think MI should be used as a programming language. I don't think -thread-select should be used by the front end except when the user explicitly requests to change threads. In fact, I would even suggest that there should be no -thread-select and that all MI commands should be reflective and not change the state of GDB or the inferior. With a complete set of notifications, the usual CLI commands could be used to change state and the front end could just parse the MI output. > As an aside, this is similar to notifications/signals in GUI libraries -- > for example, line edit control often has 'text changed' signal. If this > signal is emitted even when the text is changed programmatically, the > application often has to specially prevent signals emitted as result of > programmatic change to be handled as if it was the user input. > > So, I think that -thread-select *should not* emit thread-changed > notification. With the original version of your patch, it would be a > one-line change, it's probably a bit harder with the last version. But the first patch was wrong for other reasons, as Pedro pointed out. -- Nick http://www.inet.net.nz/~nickrob