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

Jamie Lokier <[email protected]> writes:
> Jim Blandy wrote:
> > Using __thread variables is async-safe.
> 
> 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.
> 
> In principle I'd expect the compiler to use pthread_key_getspecific()
> or some similar low level libc routine to access variables declared in
> that way although I don't know if any actually do that.

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.)

> > pthread_self (which isn't officially async-signal-safe, but geez)
> 
> On some implementations pthread_self has to search a data structure
> which is modified and hence locked whenever threads are created or
> destroyed.  It's not surprising that it's not async-signal-safe.  I
> think an older version of Glibc threads was like this on some
> architectures.

You're right.  I have learned a bit more since I wrote that comment,
and should re-tone it.