On Thursday, 2 July 2020 at 12:36:09 UTC, IGotD- wrote:
On Thursday, 2 July 2020 at 11:13:41 UTC, claptrap wrote:
If you're doing a plugin the host callback thread wont be
known to the D runtime and so the GC wont pause it. So as long
as you dont call anything that might trigger the GC while in
the callback you wont get GC pauses affecting the audio
rendering. This can be mechanically checked by the compiler
with the @nogc attribute.
The point is even in C++ you should never ever do malloc/free
in the audio thread, you might get away with it under low CPU
load, but if you're running at high load it can barf the
audio. So GC is just a variation on the same problem. Dont
call malloc/free, dont use GC in anyway.
You also have to make sure that the GC knows about your
pointers, so if you have a pointer to something, make sure
it's reachable from stuff the GC will scan. If it exists only
on the stack in the audio thread the GC could collect it as it
wont know it is still in use.
Also see this...
https://github.com/AuburnSounds/Dplug
I think you can make a callback thread to D work if you have a
trampoline function and then call
thread_attachThis
rt_moduleTlsCtor
before calling the actual callback. Then the thread will be
known to D runtime.
Sorry maybe I was unclear, I'm saying keep the real time thread
hidden from D runtime & GC. Just make sure any GC memory
referenced by the real time thread is also referenced in the
threads/data that is known about by the runtime / GC. Or only
pass the real time threa malloced memory.
