From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7431 invoked by alias); 14 Jun 2008 18:19:32 -0000 Received: (qmail 7420 invoked by uid 22791); 14 Jun 2008 18:19:31 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 14 Jun 2008 18:19:06 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m5EIEj4k025990; Sat, 14 Jun 2008 14:14:45 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5EIEjtU026336; Sat, 14 Jun 2008 14:14:45 -0400 Received: from opsy.redhat.com (vpn-10-33.bos.redhat.com [10.16.10.33]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5EIEiuH027485; Sat, 14 Jun 2008 14:14:44 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id C933050845B; Sat, 14 Jun 2008 12:14:43 -0600 (MDT) To: Vladimir Prus Cc: Daniel Jacobowitz , Nick Roberts , Pedro Alves , gdb-patches@sourceware.org Subject: Re: [patch:MI] Observer for thread-changed References: <18509.7945.19078.399646@kahikatea.snap.net.nz> <200806101027.38454.ghost@cs.msu.su> <20080610132512.GB7986@caradoc.them.org> <200806141909.37719.ghost@cs.msu.su> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom Date: Sat, 14 Jun 2008 19:13:00 -0000 In-Reply-To: <200806141909.37719.ghost@cs.msu.su> (Vladimir Prus's message of "Sat\, 14 Jun 2008 19\:09\:37 +0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00264.txt.bz2 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. 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? Tom