dlopen/dlclose thread safety

[Mike Frysinger]

2011/3/23 Timo Teräs:
> On 03/23/2011 06:33 PM, Mike Frysinger wrote:
>> On Wed, Mar 23, 2011 at 12:29 PM, Carmelo AMOROSO wrote:
>>> indeed we have seen also some issue with dlopen, when TLS variables were
>>> involved. One suspect we have is actually thread-safety. glibc use some
>>> locking primitives to access TLS block, while we don't.
>>> Not yet had a free time slot to look at this deeply.
>>
>> i'm not sure how thread safety would play a role with TLS variables.
>> TLS, by definition, is per-thread and that is guaranteed by the
>> ABI/compiler/C lib/kernel down to the variable level, and that whole
>> stack shouldnt be poking into any shared state (beyond shared .text).
>
> ldso needs to allocate each global TLS variable from globally single
> place. That's how it organises the per-thread data area. So yes, when dl
> allocates the TLS variables it needs to go fiddle global variables.

mmm my understanding was that each thread got its own chunk of TLS
area at thread creation time, and after that the ldso only existed
when the thread needed to know the address of its TLS.  what port are
you talking about exactly ?
-mike