This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Async signal safe TLS accesses


On Wed, Oct 02, 2013 at 03:17:43PM -0700, Ian Lance Taylor wrote:
> On Wed, Oct 2, 2013 at 3:08 PM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> >
> > I do think there is consensus for allowing TLS access in signal handlers.
> > I'd like there to be consensus for TLS accesses never failing (i.e. all
> > dynamic allocation being done at thread creation time or dlopen time, when
> > it's possible to return an error status, and initial accesses doing no
> > more than associating a variable with memory from a pool where a
> > sufficient amount of memory is guaranteed to have been allocated at one of
> > those times), but while I don't think anyone has objected to that, I'm not
> > sure enough people have actually thought about it.
> 
> I agree, but for some initial thoughts see
> 
> https://sourceware.org/ml/libc-alpha/2012-06/msg00386.html

The idea that dlopen has to poke at all existing threads is wrong.
That's the complex, error-prone way to implement safe TLS allocation.
The other way is to simply allocate sufficient space (including space
for enlarged DTVs) for the currently existing number of threads, but
wait to give it to them until they call __tls_get_addr.

In musl, this is done with a single allocation of the appropriate
size. If it's desirable for these blocks to be individually freeable,
N allocations could be performed for the N existing threads, and an
array of pointers to these N blocks should be allocated as part of the
DSO bookkeeping. When a thread needs to get its block, it could do so
by performing an atomic fetch-and-add on the index into this array,
taking ownership of the pointer at the index it read and using this
for its TLS block.

There may be additional logic that needs to be considered for dlclose,
but the above basically covers the design, and I don't forsee problems
in fleshing out the rest of it.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]