From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9788 invoked by alias); 14 Sep 2005 22:09:21 -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 9446 invoked by uid 22791); 14 Sep 2005 22:08:54 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 14 Sep 2005 22:08:53 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EFfQx-0003Ku-Ne for rda@sources.redhat.com; Wed, 14 Sep 2005 18:08:52 -0400 Date: Wed, 14 Sep 2005 22:09:00 -0000 From: Daniel Jacobowitz To: rda@sources.redhat.com Subject: Re: [RFC] Improve performance of multi-threaded debugging Message-ID: <20050914220851.GA12788@nevyn.them.org> References: <20050914150439.5a86df49@ironwood.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050914150439.5a86df49@ironwood.lan> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-q3/txt/msg00004.txt.bz2 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. -- Daniel Jacobowitz CodeSourcery, LLC