is d-runtime non-gc safe?

[Sean Kelly]

You can make the GC know about any thread you want. Look at thread_attachThis and related routines in core.thread. 

Sent from my iPhone

On Dec 4, 2011, at 5:08 AM, Norbert Nemec <Norbert at Nemec-online.de> wrote:

> On 04.12.2011 09:10, Marco Leise wrote:
>> Am 03.12.2011, 19:47 Uhr, schrieb Andrej Mitrovic
>> <andrej.mitrovich at gmail.com>:
>> 
>>> On 12/3/11, Marco Leise <Marco.Leise at gmx.de> wrote:
>>>> Am 03.12.2011, 19:05 Uhr, schrieb Andrej Mitrovic
>>>> <andrej.mitrovich at gmail.com>:
>>>> 
>>>>> +1 on interest on having this. Back when I was attempting to port VST
>>>>> to D I got asked by a Steinberg dev how I can guarantee that D plugins
>>>>> will work. But I couldn't guarantee it, if a GC collection were to run
>>>>> the plugin would freeze, the host would crash, and the host company
>>>>> would likely get the blame.
>>>> 
>>>> You'll get some angry comments on this one by others. I'll lean back and
>>>> enjoy the show :D
>>>> 
>>> 
>>> I don't follow..?
>> 
>> Hmm, and no one commented either. I thought someone would jump in and
>> say that you could disable the GC and that malloc isn't realtime either
>> and for that reason the host application should not crash when a plugin
>> doesn't deliver in time. The audio should stutter and that's it. So: no
>> realtime guarantees whatsoever on consumer OSs, but a high probability
>> that it will just work.
> 
> Indeed, malloc is not real-time safe. It is common wisdom that real-time audio code should not handle any memory allocations.
> 
> To this point, D is just as safe as C++: don't do any operations that may allocate memory in the audio thread, so the GC will never be invoked in real-time critical code.
> 
> Where it gets more involved, though, is that D garbage collection is not thread safe. When it starts, all registered threads are stopped.
> 
> Note: the audio-thread is typically created externally with special settings, so D will not know about it and the GC will not stop it. As long as the audio-thread never does any pointer assignments that are relevant to the GC, everything should be safe.
> 
> Just make sure that any garbage collected objects that the audio thread accesses have live pointer from areas that the GC knows about. That way it will not matter whether the GC scans the audio-data or not or whether this data is modified by the audio-thread while the GC is scanning it.