From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12021 invoked by alias); 14 Jun 2008 19:43:19 -0000 Received: (qmail 12012 invoked by uid 22791); 14 Jun 2008 19:43:19 -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; Sat, 14 Jun 2008 19:42:58 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.63) (envelope-from ) id 1K7beG-0001KA-11 for gdb-patches@sources.redhat.com; Sat, 14 Jun 2008 23:42:55 +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 1K7be0-0001Jl-FE; Sat, 14 Jun 2008 23:42:36 +0400 From: Vladimir Prus To: tromey@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [patch:MI] Observer for thread-changed Date: Sat, 14 Jun 2008 20:04:00 -0000 User-Agent: KMail/1.9.9 References: <18509.7945.19078.399646@kahikatea.snap.net.nz> <200806141909.37719.ghost@cs.msu.su> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806142342.32273.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/msg00268.txt.bz2 On Saturday 14 June 2008 22:14:43 Tom Tromey wrote: > Daniel> One method I use is to ask myself how complicated the documentation > Daniel> for something will be. It's much clearer to say "the notification is > Daniel> emitted whenever the active thread changes" than "... unless it > Daniel> changed because of -thread-select". > > Vladimir> I'm afraid you are oversimplifying -- the "the notification > Vladimir> is emitted whenever the active thread changes" is very nice, > Vladimir> but it's very likely that every frontend author will not > Vladimir> realize he has to ignore this notification from > Vladimir> -thread-select. So, the documentation should either say that > Vladimir> the notification is better ignored, or say that is not > Vladimir> emitted. Now, what is better? > > I think that the Python layer would like to be notified of every > thread change. That way, it will be possible to write Python > libraries which react to these kinds of events. What's "these kinds of events"? Are you interested in any change in inferiour_ptid? Or in any change of user's idea of what thread he wants to look at? Pedro's a patch to make those different. > If the thread-changed observer is not always notified, is there a way > to do this? I suppose we could introduce a second observer. > > Would it be possible to isolate the "don't print some thread change" > logic into MI-specific code? Say, by having MI attach to a generic > observer and then filter out the notifications it does not want to > report? I think the above question is most important to answer, but we can surely make the filtering happen in MI code, if Python wants to see all changes. - Volodya