From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21155 invoked by alias); 16 Sep 2005 20:49:51 -0000 Mailing-List: contact rda-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: rda-owner@sources.redhat.com Received: (qmail 21125 invoked by uid 22791); 16 Sep 2005 20:49:46 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 16 Sep 2005 20:49:46 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j8GKnjv3007198 for ; Fri, 16 Sep 2005 16:49:45 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j8GKnjV24829 for ; Fri, 16 Sep 2005 16:49:45 -0400 Received: from localhost.localdomain (vpn50-50.rdu.redhat.com [172.16.50.50]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id j8GKniO3016646 for ; Fri, 16 Sep 2005 16:49:45 -0400 Received: from ironwood.lan (ironwood.lan [192.168.64.8]) by localhost.localdomain (8.12.11/8.12.10) with ESMTP id j8GKndZT031502 for ; Fri, 16 Sep 2005 13:49:39 -0700 Date: Fri, 16 Sep 2005 20:49:00 -0000 From: Kevin Buettner To: rda@sources.redhat.com Subject: Re: [RFC] Improve performance of multi-threaded debugging Message-ID: <20050916134939.5ad3fe5f@ironwood.lan> In-Reply-To: References: <20050914150439.5a86df49@ironwood.lan> Organization: Red Hat X-Mailer: Sylpheed-Claws 0.9.12cvs173.1 (GTK+ 2.4.14; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2005-q3/txt/msg00008.txt.bz2 On Fri, 16 Sep 2005 13:19:57 -0700 Jim Blandy wrote: > > Kevin Buettner writes: > > The only fly in the ointment is that the signal based event model only > > knows about thread creation, but not about thread death. So it won't > > catch thread death until some new thread is created. I'm not sure > > what the implications of this are in practice. > > Even in the signal-based model, we're attached to all the threads, so > we should get a wait status via lwp_pool_waitpid. Isn't that working? It probably does, but do not know for certain. I saw that the thread list was getting fetched on every status check. My assumption was that there was some good reason for this to occur and revised the code so that it would only happen when so informed by the event model. What I did not investigate is whether the thread refetch ever really needs to happen at all. Kevin