From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 794 invoked by alias); 5 Nov 2004 01:28:59 -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 778 invoked from network); 5 Nov 2004 01:28:59 -0000 Received: from unknown (HELO palrel13.hp.com) (156.153.255.238) by sourceware.org with SMTP; 5 Nov 2004 01:28:59 -0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by palrel13.hp.com (Postfix) with ESMTP id 8C50C1C045DC; Thu, 4 Nov 2004 17:28:58 -0800 (PST) Received: from napali.hpl.hp.com (napali.hpl.hp.com [15.4.89.123]) by hplms2.hpl.hp.com (8.13.1/8.13.1/HPL-PA Hub) with ESMTP id iA51SuMn005328; Thu, 4 Nov 2004 17:28:57 -0800 (PST) Received: from napali.hpl.hp.com (napali [127.0.0.1]) by napali.hpl.hp.com (8.13.1/8.13.1/Debian-16) with ESMTP id iA51SuXu008993; Thu, 4 Nov 2004 17:28:56 -0800 Received: (from davidm@localhost) by napali.hpl.hp.com (8.13.1/8.13.1/Submit) id iA51Sujg008990; Thu, 4 Nov 2004 17:28:56 -0800 From: David Mosberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16778.55128.102064.331295@napali.hpl.hp.com> Date: Fri, 05 Nov 2004 01:28:00 -0000 To: Roland McGrath Cc: davidm@hpl.hp.com, libc-hacker@sources.redhat.com Subject: Re: second thoughts on using dl_iterate_phdr() for cache-validation In-Reply-To: <200411050110.iA51ApHW004271@magilla.sf.frob.com> References: <16778.52238.419635.428364@napali.hpl.hp.com> <200411050110.iA51ApHW004271@magilla.sf.frob.com> Reply-To: davidm@hpl.hp.com X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ X-SW-Source: 2004-11/txt/msg00011.txt.bz2 >>>>> On Thu, 4 Nov 2004 17:10:51 -0800, Roland McGrath said: >> Is there a mechanism to queue this patch so it doesn't get lost >> again when 2.3.5 is opened up? Roland> It never "got lost". It's your baby, and you didn't follow Roland> up on it before now. We use bugzilla for keeping track of Roland> things, but something can sit there unattended just as well Roland> if you don't stay on top of it. So when should I check back? >> The incrementing is always done under protection of a lock. The >> reading is not, but on those machines where reading an "unsigned >> long long int" isn't atomic, the effect is no worse than when >> using "unsigned int". And on those machines where it is atomic, >> "unsigned long long int" pretty much guarantees that the counter >> will never overflow. Roland> Either it's a counter with a robust well-defined semantics, Roland> or it's not. If it's not reliably usable as a counter, then Roland> there is no reason to call it one. Fine; I don't mind changing it back to "unsigned long int". --david