static ctors in shared libs

[bitwise via Digitalmars-d]

On Friday, 18 March 2016 at 18:52:25 UTC, Jacob Carlborg wrote:
> On 17/03/16 21:27, bitwise wrote:
>> I've been doing some work on shared libraries for OSX, and 
>> have come
>> across a potential problem, which I'm not sure what to do with.
>>
>> Currently, when a thread is spawned, that thread calls all the 
>> TLS
>> ctors, then runs the thread entry point function, and finally 
>> calls the
>> TLS dtors before the thread terminates.
>>
>> Example, for windows:
>>
>> https://github.com/D-Programming-Language/druntime/blob/15a227477a344583c4748d95492703901417f4f8/src/core/thread.d#L236
>>
>>
>> So, the question is, how do dynamic libraries interact here?
>>
>> Example: A dynamic library contains D modules with TLS ctors. 
>> If I start
>> a few threads, and then load a dynamic library, shouldn't the 
>> TLS ctors
>> in the dynamic library be called for each running thread? If my
>> assumption is correct, the next question is, how do you do 
>> this?
>>
>> I don't think you can hijack each thread and have it run the 
>> TLS ctors,
>> and you can run them all from the thread loading the shared 
>> library
>> because of synchronization issues. So what's the solution? 
>> Should TLS
>> ctors in dynamic libraries simply be specified not to run, or 
>> could they
>> somehow be run lazily at the first TLS access in a dynamic 
>> library?
>>
>> Any thoughts on this would be appreciated.
>
> How does it behave on Linux? It already supports dynamic 
> libraries.

After looking at the elf implementation, Johannes's explanation 
seems to be correct. I don't think it's the best solution though.

I'm wondering if the _exact_ behavior of the current solution was 
intentional. It seems like everything will work fine as long as 
you only use statically linked shared libs, so I'm wondering if 
dynamic linking was fully considered at the time the current 
solution was written. As far as dynamic linking goes, I don't 
like how the current solution works. It can lead to very 
confusing problems, and I think it would be better to do an 
all-or-nothing approach:

-statically linked shared libs always have shared static ctors 
called
-statically linked shared libs always have TLS static ctors 
called for all new threads
-dynamically linked shared libs always have shared static ctors 
called
-dynamically linked shared libs NEVER have TLS static ctors 
called for ANY thread

I can see how one could argue for benefits of the current 
approach, but I don't think it's worth exposing people to that 
kind of confusion, to have partially working TLS static ctors.

Thoughts?

     Bit