• solidstate1991 (7/7) Jul 30 2021 I'm doing some audio-related work, and one thing I need is to
• WebFreak001 (8/15) Aug 01 2021 There is an idiom on d-idioms that probably fits what you needs:
• user1234 (13/21) Aug 01 2021 GC + audio is only a problem if its pauses (e.g in the audio
• Guillaume Piolat (6/9) Aug 02 2021 The consequence is that the stack memory of that thread isn't

solidstate1991 <laszloszeremi outlook.com> writes:

I'm doing some audio-related work, and one thing I need is to 
unregister from (and maybe later temporarily re-register to) the 
GC, since it would cause some issues, and it would be nice if I 
still could use the GC during disk operations, etc.

Info on it is quite scarce and a bit confusing. If I unregister 
from the RT, will that mean it'll be GC independent, or will have 
other consequences too?

WebFreak001 <d.forum webfreak.org> writes:

On Friday, 30 July 2021 at 23:48:41 UTC, solidstate1991 wrote:
 I'm doing some audio-related work, and one thing I need is to 
 unregister from (and maybe later temporarily re-register to) 
 the GC, since it would cause some issues, and it would be nice 
 if I still could use the GC during disk operations, etc.

 Info on it is quite scarce and a bit confusing. If I unregister 
 from the RT, will that mean it'll be GC independent, or will 
 have other consequences too?

There is an idiom on d-idioms that probably fits what you needs: 
https://p0nce.github.io/d-idioms/#The-impossible-real-time-thread

Additional documentation:
- 
https://github.com/dlang/druntime/blob/c3a4c51773e88c68dc3efa73335befdb74d17242/src/core/thread/threadbase.d#L827
- 
https://github.com/dlang/druntime/blob/078cb3cdafda875a9893574fc53437908f3dfd26/src/core/thread/osthread.d#L1267

user1234 <user1234 12.de> writes:

On Friday, 30 July 2021 at 23:48:41 UTC, solidstate1991 wrote:
 I'm doing some audio-related work, and one thing I need is to 
 unregister from (and maybe later temporarily re-register to) 
 the GC, since it would cause some issues,

GC + audio is only a problem if its pauses (e.g in the audio 
thread) are longer than the time required to create a buffer (as 
obviously computer audio is **not real-time**).

Let's say you have 3 msecs GC pause, 12 msecs to create a buffer, 
if the driver latency is of 22 msecs then the rendering will not 
be affected, e.g when the driver reclaims a buffer it is ready 
and no perceptible crackling occurs.

 and it would be nice if I still could use the GC during disk 
 operations, etc.

 Info on it is quite scarce and a bit confusing. If I unregister 
 from the RT, will that mean it'll be GC independent, or will 
 have other consequences too?

Mixin C heap memory and GC memory is a known source of issues 
because of GC roots.

A simpler solution is to continue using the GC memory (e.g `new`) 
but control manually when it runs using `GC.enable`, `GC.disable` 
and `GC.collect`, `GC.minimize`.

Guillaume Piolat <first.last gmail.com> writes:

On Friday, 30 July 2021 at 23:48:41 UTC, solidstate1991 wrote:
 Info on it is quite scarce and a bit confusing. If I unregister 
 from the RT, will that mean it'll be GC independent, or will 
 have other consequences too?

The consequence is that the stack memory of that thread isn't 
traced, so things that are only "owned" pointed to transitively 
by pointers on the thread stack might get collected under your 
feet.

Your thread should use things that outlive its existence.