Talk by Herb Sutter: Bridge to NewThingia

[claptrap]

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