From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28508 invoked by alias); 14 Sep 2005 22:31:44 -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 28478 invoked by uid 22791); 14 Sep 2005 22:31:39 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 14 Sep 2005 22:31:39 +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 j8EMVbu1011114 for ; Wed, 14 Sep 2005 18:31:37 -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 j8EMVbV03642 for ; Wed, 14 Sep 2005 18:31:37 -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 j8EMVb8M019424 for ; Wed, 14 Sep 2005 18:31:37 -0400 Received: from ironwood.lan (ironwood.lan [192.168.64.8]) by localhost.localdomain (8.12.11/8.12.10) with ESMTP id j8EMVVX9025884 for ; Wed, 14 Sep 2005 15:31:31 -0700 Date: Wed, 14 Sep 2005 22:31:00 -0000 From: Kevin Buettner To: rda@sources.redhat.com Subject: Re: [RFC] Improve performance of multi-threaded debugging Message-ID: <20050914153131.4924147d@ironwood.lan> In-Reply-To: <20050914220851.GA12788@nevyn.them.org> References: <20050914150439.5a86df49@ironwood.lan> <20050914220851.GA12788@nevyn.them.org> 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/msg00005.txt.bz2 On Wed, 14 Sep 2005 18:08:51 -0400 Daniel Jacobowitz wrote: > On Wed, Sep 14, 2005 at 03:04:39PM -0700, Kevin Buettner wrote: > > As things stand now, the thread list is fetched each time rda checks > > the status of the program. This doesn't sound like such a burden until > > you realize that some decent sized data structures are read via the > > ptrace() interface. On slower machines, it can take a significant amount > > of time to single step or continue primarily due to this overhead. > > > > The patch below fetches the thread list only when it knows for certain > > that something has changed. > > > > 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. > > You may run a risk of not noticing when a thread is destroyed > and then a new thread is created with the same thread ID - which NPTL > does all the time. > > Other than that I haven't looked at rda enough to comment. I'm not > sure what you mean about not knowing about thread death; you ought to > be notified about thread death (A) via TD_* and (B) via wait, except on > some broken RH 2.4 kernels. I have the TD_ case taken care of. My patch didn't address the wait() case though. Thanks for your comments! Kevin