Leave GC collection to the user of the D library?

[Ali Çehreli]

On 5/9/21 1:09 AM, Daniel N wrote:

 > On Sunday, 9 May 2021 at 03:25:06 UTC, Ali Çehreli wrote:
 >> tl;dr I am scared of non-D programs calling my D library functions
 >> from foreign threads. So, I am planning on asking the user to trigger
 >> collection themselves by calling a collection function of my library.
 >> Crazy?
 >>
 >
 > Since this is a "thin" library, feels like the sane solution is to make
 > it 100% nogc and keep the GC only in the server.

May not be possible because the library creates MmFile objects as needed 
(the data length to be placed on shared memory is not known in advance). 
Being a class, MmFile objects are naturally created with 'new' but 
perhaps placement new could work. I haven't investigated that.

 > But might not be possible if the design of those other libraries are
 > all-in on GC
 > "this library itself loads other D libraries"

I wasn't clear on that part: Now that the library is thin, loading other 
D libraries has already been pushed to the backend daemon.

So, my worry is based on my unconfidence in managing foreign threads 
with thread_attachThis and thread_detachThis. Should I use a 
thread-local Boolean to keep track? Should I call those inside 'static 
this' and 'static ~this' blocks? What if the thread dies? I see that 
even the name of the functions gained a "_tpl":

 
https://dlang.org/phobos/core_thread_threadbase.html#.thread_attachThis_tpl

I wonder what "_tpl" means. It mentions rt_moduleTlsCtor() there.

Failing to find my way through all of that is the reason why I am hoping 
that I can push a GC collection cycle to the caller. Although 
embarrassing, it seems to be a more reliable design because the user is 
in a better position to know they are not executing any of the D library 
functions when they call the collection function.

Ali