Talk by Herb Sutter: Bridge to NewThingia
clap at trap.com
Thu Jul 2 14:44:50 UTC 2020
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...
> I think you can make a callback thread to D work if you have a
> trampoline function and then call
> 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.
More information about the Digitalmars-d-announce