On Sunday, 27 March 2016 at 03:28:31 UTC, bitwise wrote:
>
> I was hoping to have some more people weigh in with their experience with plugins, whether or not they're expected to be multi-threaded, thread-safe, etc.. I think the current design is fragile, and given the limited usage of D shared libraries atm, I think it's a good time to come up with something a bit more solid/predictable.

Using OSX shared libraries with both DMD and LDC for plugins, I'm trying to avoid all TLS, with LDC the only TLS I have is cached Obj-C selectors (pointers) which do not have constructors IIRC.

A real concern is then that Phobos would use TLS internally. Apart from that I don't really have an opinion.

On Sunday, 27 March 2016 at 11:38:15 UTC, Guillaume Piolat wrote:
> On Sunday, 27 March 2016 at 03:28:31 UTC, bitwise wrote:
>>
>> I was hoping to have some more people weigh in with their experience with plugins, whether or not they're expected to be multi-threaded, thread-safe, etc.. I think the current design is fragile, and given the limited usage of D shared libraries atm, I think it's a good time to come up with something a bit more solid/predictable.
>
> Using OSX shared libraries with both DMD and LDC for plugins, I'm trying to avoid all TLS, with LDC the only TLS I have is cached Obj-C selectors (pointers) which do not have constructors IIRC.
>
> A real concern is then that Phobos would use TLS internally. Apart from that I don't really have an opinion.

Ok, thanks!

Phobos should be linked statically even when it's a shared library, so it should still have all static ctors called properly.

    Bit

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.

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.

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

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

On Sunday, 27 March 2016 at 22:08:57 UTC, bitwise wrote:
>
> 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.

That looks more sensible indeed.