From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17063 invoked by alias); 10 Jun 2008 06:39:38 -0000 Received: (qmail 17055 invoked by uid 22791); 10 Jun 2008 06:39:37 -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 06:39:20 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.63) (envelope-from ) id 1K5xVd-0005bi-RZ for gdb-patches@sourceware.org; Tue, 10 Jun 2008 10:39:16 +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 1K5xVQ-0005at-Fa; Tue, 10 Jun 2008 10:38:56 +0400 From: Vladimir Prus To: Nick Roberts Subject: Re: [patch:MI] Observer for thread-changed Date: Tue, 10 Jun 2008 08:26:00 -0000 User-Agent: KMail/1.9.9 Cc: Pedro Alves , gdb-patches@sourceware.org References: <18509.7945.19078.399646@kahikatea.snap.net.nz> <200806100104.28694.pedro@codesourcery.com> <18509.57602.879804.675918@kahikatea.snap.net.nz> In-Reply-To: <18509.57602.879804.675918@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200806101027.38454.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/msg00191.txt.bz2 On Tuesday 10 June 2008 06:03:46 Nick Roberts wrote: > > It all amounts to: > > > > - should there be an MI async event on -thread-select if the > > reply already carries that information? > > But the CLI command "thread" doesn't. I think MI should try to reflect the > state of GDB and the inferior. It shouldn't really matter what commands were > used to put it in that state. We had this discussion in context of breakpoint notifications already, but I think the thread notification makes those issues easier to discuss. What is the purpose of the thread change notification? I think the purpose is to enable the frontend to notice when the thread change, unexpectedly. For example, due to "thread" CLI command or user-defined command that switches threads, or due to an otherwise magical way. The frontend, most likely, should react by marking the thread reported as selected by GDB also selected in GUI. 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. 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. - Volodya