From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19224 invoked by alias); 12 Mar 2002 03:23:32 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 19151 invoked from network); 12 Mar 2002 03:23:30 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 12 Mar 2002 03:23:30 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16kcsw-0000qM-00; Mon, 11 Mar 2002 22:23:34 -0500 Date: Mon, 11 Mar 2002 19:23:00 -0000 From: Daniel Jacobowitz To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH RFA/RFC] Don't use lwp_from_thread() in thread_db_wait() Message-ID: <20020311222334.A3178@nevyn.them.org> Mail-Followup-To: Kevin Buettner , gdb-patches@sources.redhat.com References: <1020311234554.ZM20650@localhost.localdomain> <20020311214703.A462@nevyn.them.org> <1020312031619.ZM21458@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1020312031619.ZM21458@localhost.localdomain> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-03/txt/msg00175.txt.bz2 On Mon, Mar 11, 2002 at 08:16:19PM -0700, Kevin Buettner wrote: > I think that an LWP id cache is only useful so long as all of the > threads are stopped. This is because the mappings could change in the > course of running the program. So, for this particular case, where > the threads are running and we want to wait for one of them to stop, > the cache wouldn't be useful to us. > > Of course, if we have knowledge that a particular thread > implementation never changes its mappings or perhaps only changes its > mappings for certain threads, we might be able to use such a cache > across the stop/start transitions. However, I think that Mark had > intended for thread-db.c to be a fairly generic solution that's not > wedded to any one particular thread implementation. In particular, it > should be possible to use it with an M:N model in which a thread may > migrate from one LWP to another. This implies that part of the caching should be in lin-lwp.c rather than in thread-db.c... that knowledge belongs with the lower level threading layer. Does that make sense? We could also, for instance, update the cache via thread event reporting... > That said, the LWP<->TID mapping operations are farily expensive > (since they involve fairly sizable target memory reads), and I agree > that an LWP cache would be beneficial even if it needs to be > invalidated when the program starts again. Definitely. I profiled this segment of GDB once not long ago; this and the is_alive checks dominated the profile. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer