Talk by Herb Sutter: Bridge to NewThingia

[claptrap]

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.