static ctors in shared libs

[bitwise via Digitalmars-d]

On Sunday, 27 March 2016 at 19:31:46 UTC, Guillaume Piolat wrote:
> On Sunday, 27 March 2016 at 17:58:01 UTC, bitwise wrote:
>> On Sunday, 27 March 2016 at 16:54:53 UTC, bitwise wrote:
>>
>>> Phobos should be linked statically even when it's a shared 
>>> library, so it should still have all static ctors called 
>>> properly.
>>>
>>>     Bit
>>
>> Correction...Phobos would be statically linked to a 
>> dynamically loaded shared library. This could be a problem.
>
> Hasn't seen any practical problem with that, not sure why 
> people say it's a bad idea TBH. I like that everything is in a 
> single static binary.

I'm not sure I understand what you're saying here.

What I'm suggesting is that TLS static ctors not be run at all 
for dynamically loaded shared libraries, because at present, they 
are only run in certain circumstances, which can be confusing and 
unreliable. For example, if a program launched a bunch of worker 
threads, and then reloaded a D shared library, the TLS static 
ctors wouldn't be run after the second reload for those worker 
threads. So if the worker threads started accessing the shared 
library, they could encounter uninitialized data.

If TLS static ctors simply weren't run at all for dynamically 
loaded libraries, there would be no confusion. Any D user that 
tried to explore the use of shared libraries, would quickly learn 
that TLS ctors are not called at all for dynamically loaded 
libraries. I suppose then, that an API like 
Runtime.AttachToThread() could be used to explicitly call the TLS 
ctors.

> The way bigger problem being OSX shared libraries unloading 
> (with the leaking workaround), I haven't really followed your 
> work recently about it!

I successfully modified DMD to output ctor/dtors which replace 
the need for the problematic callback, but I have to wait for 
Jacob's work on native TLS to be merged before I can continue.

      Bit