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]

TLS limitations


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]