This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
>>>>> On Sat, 17 Jan 2004 00:29:31 +0100, Jakub Jelinek <jakub@redhat.com> said: Jakub> On Fri, Jan 16, 2004 at 04:57:26PM -0800, Roland McGrath wrote: >> > In any case, if a callback-based approach is preferred, I can live >> > with that, too. >> I don't claim it's the best interface. But that is the approach that >> doesn't have other blocking issues right now. Jakub> How about extending struct dl_phdr_info and passing an counter in it Jakub> to dl_iterate_phdr's callback? Jakub> The structure can be extended at the end, because dl_iterate_phdr Jakub> passes its size to the callback as well. Jakub> The callback is called with dl_load_lock held, so the counter doesn't Jakub> even have to be atomic. Jakub> libgcc_s would just see if size includes the additional field in the Jakub> first callback, if yes, it would record that counter and on subsequent Jakub> dl_iterate_phdr call it would first check whether the counter did not Jakub> change and if it is the same, it could use cached info. Sounds good to me. I assume it'd be OK to have separate "additions" and "removals" counters? Only the latter is needed for avoiding stale values in a cache, but the former helps performance, because dl_iterate_phdr() can be stopped early if we know that the list didn't change. I'd be happy to prototype the necessary code, but at the moment, glibc doesn't build for me on ia64 (it crashes in rpcgen). I assume that's due to the stuff Uli is working on. --david
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |