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

> The __thread variable is static to a compilation unit which will be
> included in a shared library, so I think the local dynamic model is
> the best the compiler can use.  The static and initial-exec models are
> out of reach.

You can use the initial-exec model in a shared library if you choose to.
This rules out loading that library via dlopen, however.  (Actually, there
is some provision for a little space to be assigned to static-TLS libraries
loaded later on, so you might get lucky.)

> My __thread structure contains the links of the list of threads to
> send signals to.  Both adding threads to the list and traversing the
> list sending signals require code to hold the same mutex.  So I have
> always referenced my thread structure before using it in the signal
> handler.  And I don't make any first references to TLS in my signal
> handlers.  So it sounds like I'm okay.

Yes.

> While I appreciate your explanation, the paragraph above is not the
> sort of language one would want to put in a spec.  When POSIX gets
> around to recognizing the existence of __thread variables, it will
> need to find a description of what is permissible that reveals less
> about the implementation.  I hope they will not simply declare it
> non-async-safe altogether.

Unfortunately, that seems like the most sensical straightforward definition.