second thoughts on using dl_iterate_phdr() for cache-validation
David Mosberger
davidm@napali.hpl.hp.com
Fri Nov 5 01:28:00 GMT 2004
>>>>> On Thu, 4 Nov 2004 17:10:51 -0800, Roland McGrath <roland@redhat.com> 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
More information about the Libc-hacker
mailing list