From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22074 invoked by alias); 6 Jun 2008 01:06:38 -0000 Received: (qmail 22064 invoked by uid 22791); 6 Jun 2008 01:06:38 -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; Fri, 06 Jun 2008 01:06:20 +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 m5616IKi003862 for ; Thu, 5 Jun 2008 21:06:19 -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 m5616IwJ015114; Thu, 5 Jun 2008 21:06:18 -0400 Received: from opsy.redhat.com (vpn-10-81.bos.redhat.com [10.16.10.81]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5616IVF013552; Thu, 5 Jun 2008 21:06:18 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 613C6508249; Thu, 5 Jun 2008 19:06:17 -0600 (MDT) To: Nick Roberts Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Another annotation for threads References: <18483.36546.101715.670386@kahikatea.snap.net.nz> <20080605193017.GF25085@caradoc.them.org> <18504.22662.394416.990603@kahikatea.snap.net.nz> <20080605212615.GA6969@caradoc.them.org> <18504.35208.397231.7949@kahikatea.snap.net.nz> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom Date: Fri, 06 Jun 2008 01:06:00 -0000 In-Reply-To: <18504.35208.397231.7949@kahikatea.snap.net.nz> (Nick Roberts's message of "Fri\, 6 Jun 2008 12\:49\:12 +1200") 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/msg00091.txt.bz2 >>>>> "Nick" == Nick Roberts writes: Nick> But that's exactly what did happen. Shortly after I submitted a Nick> patch for the "new-thread" annotation which used the new_thread Nick> observer, the observer was moved to report the main thread. Nick> It's pragmatic argument rather than technical one. I have no Nick> control over MI development and Vladimir has stated on several Nick> occasions that MI considerations are paramount. I'm curious about the long-term view in this area. I'm perhaps not as familiar with gdb history as I ought to be to enter this discussion... It seems to me that the Python work will want notification of all the same kinds of things that Emacs would, that MI would, and that Insight would -- regardless of how something happens (an independent event in the inferior, code run from Python, or user activity on the CLI), folks will want to be able to write Python that reacts to these somethings. Abstractly I would have expected that the gdb core would use observer notification, and the various state-change consumers (MI, annotations, Python, etc) would simply register observers as needed. (At least, this is what I expected once I found out that events are deprecated. I already had to add a couple of observers for Python, so this isn't totally theoretical for me.) Is this how things "ought" to work? I mean ideally? If not, would someone mind summarizing how it really should work? Tom