From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30694 invoked by alias); 10 Jun 2008 09:24:23 -0000 Received: (qmail 30684 invoked by uid 22791); 10 Jun 2008 09:24:23 -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; Tue, 10 Jun 2008 09:24:05 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.63) (envelope-from ) id 1K6059-0001T6-0G for gdb-patches@sources.redhat.com; Tue, 10 Jun 2008 13:24:02 +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 1K6052-0001Sn-1o; Tue, 10 Jun 2008 13:23:52 +0400 From: Vladimir Prus To: Nick Roberts , gdb-patches@sources.redhat.com Subject: Re: [patch:MI] Observer for thread-changed Date: Tue, 10 Jun 2008 10:26:00 -0000 User-Agent: KMail/1.9.9 References: <18509.7945.19078.399646@kahikatea.snap.net.nz> <200806101027.38454.ghost@cs.msu.su> <18510.15829.135063.624409@kahikatea.snap.net.nz> In-Reply-To: <18510.15829.135063.624409@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806101323.49926.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/msg00196.txt.bz2 On Tuesday 10 June 2008 12:39:49 you wrote: > > 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. No, because user-defined functions are typed by the user and passed through to GDB, and if those commands change thread, UI should update. On the contrary, if the frontend sent -thread-select, it means it wanted to set GDB current thread to be the same as the current thread presently shown in the UI, so I see no point for frontend to be notified. Can you outline a use case where frontend would actually like to be notified about the thing it just did? > 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 What is "reflective"? > and not change > the state of GDB or the inferior. Even though the patch that adds --thread option to all MI commands is almost ready, I'd expect some frontends not to update for a while, and IIUC, Eclipse DSF is not actually willing to update at all. So, frontends will be using -thread-select for all purposes. > 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. Could be used where? If in GDB console, then sure, but that does not require that -thread-select output notification. > > 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. IIUC, the primary objection was that we'd emit notification even if gdb_thread_select caught an exception. Can we protect against this by checking that inferior_ptid actually changed? - Volodya