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
