From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Received: (qmail 22605 invoked from network); 11 Jan 2003 12:14:18 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.250) by 209.249.29.67 with SMTP; 11 Jan 2003 12:14:18 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6/8.12.5) with ESMTP id h0BCDxoJ000281; Sat, 11 Jan 2003 13:13:59 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6/8.12.6) with ESMTP id h0BCDtNP000391; Sat, 11 Jan 2003 13:13:55 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6/8.12.6/Submit) id h0BCDtxE000390; Sat, 11 Jan 2003 13:13:55 +0100 (CET) To: gdb-patches@sources.redhat.com Cc: drow@mvista.com Subject: Re: RFA [threads]: Thread cache References: <20030110204624.GA32002@nevyn.them.org> MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII From: Mark Kettenis Date: Sat, 11 Jan 2003 12:14:00 -0000 In-Reply-To: <20030110204624.GA32002@nevyn.them.org> (Daniel Jacobowitz's message of "Fri, 10 Jan 2003 15:46:24 -0500") Message-ID: <86wulbc29o.fsf@elgar.kettenis.dyndns.org> User-Agent: T-gnus/6.15.8 (based on Oort Gnus v0.08) (revision 05) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) X-SW-Source: 2003-01/txt/msg00448.txt.bz2 Daniel Jacobowitz writes: > I've figured out how to fix print-threads.exp (see my ramblings on gdb@ > yesterday for a bad description of the problem; better coming soon). > However, to do it, I discovered that it was actually _required_ that we > cache certain information from libthread_db, instead of merely beneficial. > > So I implemented the cache. This patch is the entire cache mechanism, > except for updating the comment at the top of the file saying we need one. > Before I get to the patch itself, some numbers: This looks good! Please check it in, regardless of the things I say further on in this message. > Now, on to the patch itself. I replace all calls to td_ta_map_id2thr_p > and most calls to td_thr_get_info_p [Hmm, I don't see any reason not to > convert the others too; I will do that in a separate patch if this one is > approved, and see how much more it takes off the runtime] with calls to > wrapper functions which cache the data in the struct private_thread_info. > The cache is invalidated at every resume(); there's some information that we > could keep if we are guaranteed a 1-to-1 threads implementation with no > migration, like LinuxThreads or NPTL, but I'm being conservative for now. Note that the thread_db.h interface provides TD_SWITCHTO and TD_SWITCHFROM events. I'd be perfectly happy if you'd cache info about the LWP a particular user-level thread is bound to if you'd invalidate this info upon receiving those events (which should never happen in a 1-to-1 threads implementation. That said, would re-enabling TD_DEATH events somehow make things more robust for you? TD_DEATH was broken in glibc 2.1.3, but anybody who's doing any serious threads development should be using a more recent glibc. > The call to target_pid_to_str is moved below the call to add_thread in > attach_thread(), since the cache requires that a struct thread_info * exist > for the ptid being printed. Makes sense. > Oh, and in thread_db_pid_to_str I replace an error () with putting "Missing" > into the string; there's no point in target_pid_to_str failing, since it's > only used for display. Fine with me. Thanks! Mark