Leave GC collection to the user of the D library?

[Ola Fosheim Grøstad]

On Sunday, 9 May 2021 at 10:27:04 UTC, Ali Çehreli wrote:
> That's what I want to do but those threads are created by the 
> user, unknown to the D GC. Although there are ways of dealing 
> with that case[1], I am questioning whether the library can 
> disable GC and lets the user manage GC collections explicitly 
> (cooperatively?).

Wouldn't this be annoying for the user of the library? (Or maybe 
you only have a handful users?).

I have to admit I haven't read about IPC in a decade or so, but 
it seems to me that there are many options? Like, if you have N 
cores, create N worker threads in the daemon and create N pipes? 
Then set the count of the semaphore to N, so when the semaphore 
hits 0 all pipes are in use, and the calling thread will wait in 
the API stub (wrapper function) until a worker thread is 
available? Kinda clunky, but fits your model... I guess.

But maybe you want to get rid of the daemon? In that case I 
probably would just use mailboxes and wrap the API in futures if 
the work isn't fine-grained, but I don't know what kind if 
library you are making...