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] |
I forgot to point out the "limitations" of the implementation. The dtv includes a generation counter. This value must be compared with < not only !=. The type for this element is size_t. This means that the counter can "only" be increment 2^32 times before it leads to problems. And there will be problems if this should happen. The counter is incremented whenever an object (or any of its dependencies) uses TLS and is loaded or unloaded. I do think it is reasonable to assume that 2^32 load and unload operations are enough even if the process runs for years. Note, objects without TLS requirement have no influence. On 64-bit systems the situation is even less restrictive since we get problems only after 2^64 operations (or to be exact 15 minutes after the universe ends). The current implementation is already a compromise. Initially I though that I could encode the current length of the thread's dtv in the generation counter but this would really restrict the range of the counter. So the length got its own place. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |