[PATCH][BZ #19329] Fix race between tls allocation at thread creation and dlopen

[Szabolcs Nagy]

On 22/01/16 14:49, Torvald Riegel wrote:
> On Tue, 2016-01-12 at 14:28 +0000, Szabolcs Nagy wrote:
>> tl;dr: if your libc has non-noop dlclose it must use a
>> global lock in dlopen/dlclose/thread creation/tls access
>> and user code must not run while that lock is held
>> (e.g. signals must be blocked)
>
> Depending on what the non-noop functionality is, it might be possible to
> still implement this in a nonblocking way (so you avoid the blocking
> sync vs. signals and reentrancy issue).

the non-noop functionality is that dlclose frees
memory that pthread_create and tls access may look at
(the link_map of a dso).

i guess lock-free garbage collection is a possibility
(e.g. refcounting, except tls access cannot call free
so it's not entirely trivial.)