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. I was worried if the dlopen searching of already loaded modules is safe. Since dlopen first checks if the module has been already loaded or not, which also touches global variables. So there's multiple places where dlopen/dlclose need to touch global data and requires mutexes. - Timo _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
