Re: Design hole in nptl (and more general in POSIX threads)

> > Are you sure?  I'd expect them to be async-signal-unsafe if there is
> > dynamic lazy resolution of __thread storage blocks, and you haven't
> > accessed that variable in that thread yet.  In your example you have
> > accessed it, obviously.
[...]
> That's what I'd think, too.  But Roland McGrath is my informant on
> this topic.  (Neither POSIX nor ISO-C say anything about it,
> obviously, since it's an extension to ISO-C and POSIX is built on
> ISO-C.)

I'm not sure if I misinformed you here, or if you misunderstood what I
said.  Lazy allocation of TLS blocks is indeed not async-signal-safe.  Use
of the static TLS block is async-signal-safe.  Use of the DTV is not truly
async-signal-safe because it can be realloc'd by an unrelated lazy
allocation in a signal handler.  But if you know that no signal handler
induces such an allocation (which none should, since it's not
async-signal-safe usage), then your non-handler code can safely use any
kind of TLS.  So, if your TLS-using code uses the static or initial-exec
TLS access model rather than one of the dynamic access models, you are fine
because at startup time you will have both allocated the space and resolved
your GOT entries (or static relocs) directly to thread-pointer offsets
(i.e. such accesses do not use the DTV).  Moreover, if you have used the
__thread variable in question in that thread already then you can always be
sure that its DTV slot for your module is allocated and safe to use as long
as no signal handler might do a lazy TLS allocation (which might realloc
the DTV).