From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30404 invoked by alias); 16 Dec 2003 19:55:05 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 30388 invoked from network); 16 Dec 2003 19:55:04 -0000 Received: from unknown (HELO palrel10.hp.com) (156.153.255.245) by sources.redhat.com with SMTP; 16 Dec 2003 19:55:04 -0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by palrel10.hp.com (Postfix) with ESMTP id 492FC1C014A7; Tue, 16 Dec 2003 11:55:04 -0800 (PST) Received: from napali.hpl.hp.com (napali.hpl.hp.com [15.4.89.123]) by hplms2.hpl.hp.com (8.12.10/8.12.10/HPL-PA Hub) with ESMTP id hBGJt3rN010702; Tue, 16 Dec 2003 11:55:03 -0800 (PST) Received: from napali.hpl.hp.com (napali [127.0.0.1]) by napali.hpl.hp.com (8.12.9/8.12.9/Debian-5) with ESMTP id hBGJt2VR003150; Tue, 16 Dec 2003 11:55:02 -0800 Received: (from davidm@localhost) by napali.hpl.hp.com (8.12.9/8.12.9/Debian-5) id hBGJsvaC003146; Tue, 16 Dec 2003 11:54:57 -0800 Date: Tue, 16 Dec 2003 19:55:00 -0000 From: David Mosberger Message-Id: <200312161954.hBGJsvaC003146@napali.hpl.hp.com> To: drepper@redhat.com Cc: libc-hacker@sources.redhat.com Subject: enabling caching for dl_iterate_phdr() X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ Reply-To: davidm@hpl.hp.com X-SW-Source: 2003-12/txt/msg00066.txt.bz2 Would it be possible to add two atomic counters, dl_load_additions and dl_load_removals, which would get incremented whenever something is a phdr is added to/removed from the list that is traversed by dl_iterate_phdr()? The motivation for this is that this would let me solve a long-standing problem with libunwind where I'd like to cache unwind-info, but cannot do so safely because there is no way for libunwind to detect efficiently when a shared object may have gotten unloaded. Having both the "additions" and "removals" counters would make it possible to cache both negative and positive information, though I'd be quite happy if there was at least a "removals" counter. Any opinions? I guess the alternative that was mentioned in the past was to use callbacks, but that seems very dangerous in regards to deadlock etc. --david