Talk by Herb Sutter: Bridge to NewThingia
clap at trap.com
Thu Jul 2 11:13:41 UTC 2020
On Thursday, 2 July 2020 at 10:13:02 UTC, Dagmar wrote:
> On Monday, 29 June 2020 at 21:29:31 UTC, Ali Çehreli wrote:
>> Then don't turn it off. :)
>> I understand there are programs where an undeterministic delay
>> in processing is unacceptable but those programs all run on
>> real-time operating systems anyway, right? ;)
> I'm working on virtual audio instruments and effect processors
> and they do their job in real-time. GC is luxury in this
> context. If I switched to D, I'd have to also switch from OOP
> to simple C-like structured programming and implement my own
> basic set of algorithms and data structures.
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
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...
More information about the Digitalmars-d-announce