This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Async signal safe TLS accesses
- From: Rich Felker <dalias at aerifal dot cx>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Carlos O'Donell <carlos at redhat dot com>, Andrew Hunter <ahh at google dot com>, GNU C Library <libc-alpha at sourceware dot org>, Paul Pluzhnikov <ppluzhnikov at google dot com>
- Date: Wed, 2 Oct 2013 18:36:12 -0400
- Subject: Re: [PATCH] Async signal safe TLS accesses
- Authentication-results: sourceware.org; auth=none
- References: <523F2ED8 dot 8090909 at redhat dot com> <1379977289-21260-1-git-send-email-ahh at google dot com> <20130924025738 dot GK20515 at brightrain dot aerifal dot cx> <524C3467 dot 2030503 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1310022203420 dot 22120 at digraph dot polyomino dot org dot uk> <CAKOQZ8wN0ecYROnxNT5edV5yxr5jiAuoLVg4ErO9DZq3SYj4HQ at mail dot gmail dot com>
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