Leave GC collection to the user of the D library?

[IGotD-]

On Sunday, 9 May 2021 at 03:25:06 UTC, Ali Çehreli wrote:
>
> That workaround seemed to be sufficient to load the library 
> successfully. Unfortunately, that was not enough to weed out 
> all issues related to libraries because this library itself 
> loads other D libraries.

Can you statically link the library so that no other D library is 
needed? Might duplicate code but whatever.

However, disable GC in D is difficult as soon some library 
function use an array for example you need the GC.

>
> This would allow the user start as many foreign threads as 
> possible. Right? Is this sane? Is collection the only issue 
> here? Do foreign threads still need to call threadAttachThis()? 
> What happens if they don't?
>
> I feel so hopeless that in the past, I even thought about and 
> experimented with banning the user from starting threads on 
> their own. Rather, they would call my library on a posix 
> compatible thread API and create their threads through me, 
> which happens to be a D thread, so no thread would be a 
> "foreign thread" and everything would work just fine. I haven't 
> deployed this crazy idea (yet).
>
> Ali

This is why I'm very opposed to any thread specific GC 
optimization. Allocated memory on GC and malloc/free must always 
be global and can operated on from any thread. Also, TLS must be 
removed from phobos/druntime so that there is basically no need 
for tracking the threads from a memory point of view, at least it 
shouldn't crash if D doesn't know about the thread unless using 
thread primitives.

Highest priority should be removing TLS totally. Second, make 
sure there is no connection between memory management and threads.