Async-signal-safe access to __thread variables from dlopen()ed libraries?

[Paul Pluzhnikov]

On 9/18/13 9:38 PM, Rich Felker wrote:

>> We really need a TLS that is both async-signal safe, and can be used from
>> dlopen()ed shared library.
>
> For what it's worth, we have fully async-signal-safe and fail-safe (no
> possibility to abort due to allocation failure) dynamic TLS in musl
> libc.

How does that work?


> Is this sufficient? Unless you take precautions, I think you could run
> into the situation where a signal handler is invoked while the thread
> is setting up its dynamic TLS, thereby possibly discarding changes
> made to TLS from the signal handler and possibly leaking memory.
> Fixing these issues is possible but difficult; the cleanest approach I
> know uses atomic operations -- something of the form:

AFAIU, Andrew's patch blocks all signals while dynamic allocation is 
taking place, to prevent self-reentry via a signal handler, and atomic 
operations to prevent a race with another thread.

But I don't (yet) understand that patch well.

Thanks,