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?

On Friday, 30 July 2021 at 23:48:41 UTC, solidstate1991 wrote:

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

On Friday, 30 July 2021 at 23:48:41 UTC, solidstate1991 wrote:

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.

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.

On Friday, 30 July 2021 at 23:48:41 UTC, solidstate1991 wrote:

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.