From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21530 invoked by alias); 16 Sep 2005 20:13: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 21411 invoked by uid 22791); 16 Sep 2005 20:13:09 -0000 Received: from nat-pool-rdu.redhat.com (HELO devserv.devel.redhat.com) (66.187.233.202) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 16 Sep 2005 20:13:09 +0000 Received: from alligator.red-bean.com.redhat.com (vpn26-3.sfbay.redhat.com [172.16.26.3]) by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j8GKD6JY008248; Fri, 16 Sep 2005 16:13:07 -0400 To: Kevin Buettner Cc: rda@sources.redhat.com Subject: Re: [RFC] Improve performance of multi-threaded debugging References: <20050914150439.5a86df49@ironwood.lan> From: Jim Blandy Date: Fri, 16 Sep 2005 20:13:00 -0000 In-Reply-To: <20050914150439.5a86df49@ironwood.lan> (Kevin Buettner's message of "Wed, 14 Sep 2005 15:04:39 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-q3/txt/msg00006.txt.bz2 Kevin Buettner writes: > 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. > > Comments? Couldn't this be done dynamically? That is, there are variables in there that indicate whether we're using the signal-based model, wherein I think we really do have to re-fetch the thread list all the time, or the libthread_db-event-based model; wherein we don't.