Leave GC collection to the user of the D library?

[Ali Çehreli]

On 5/9/21 3:42 AM, Ola Fosheim Grøstad wrote:

 > On Sunday, 9 May 2021 at 10:27:04 UTC, Ali Çehreli wrote:
 >> 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?).

Yes, would be annoying; that's why I am asking what others would think 
about this. (And yes, there are a handful of users.)

 > if you have N cores, create N
 > worker threads in the daemon and create N pipes?

That's my idea. The trouble is with the thin library layer: It cannot 
allocate memory while another one is doing collection. This is handled 
by D runtime for D threads but foreign threads (one that's created by 
e.g. the C++ program) cannot be known to the D runtime by-default.

 > 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?

That's an interesting idea! But it should be a little different: "I need 
to collect garbage; I will wait till all others are quiet (and they 
should know to wait until the collection is over); I collect garbage. 
Everybody resume." Still, this would require keeping the D GC disabled 
and my library handles collections at opportune moments that it creates.

 > But maybe you want to get rid of the daemon?

I want the daemon because a full-fledged D library that loaded its own 
libraries as neede caused issues. Perhaps they were all my mistakes but 
now that it works this way; the daemon stays. :)

Ali