is d-runtime non-gc safe?

[Walter Bright]

On 12/5/2011 11:52 AM, Norbert Nemec wrote:
> On 04.12.2011 21:04, Walter Bright wrote:
>> You're right, except for one point. If we ever do a moving GC, then the
>> GC has to either know about all the pointers (so it can modify them) or
>> the pointers must be 'pinned' (the pointed to object cannot be moved).
>>
>> The way to 'pin' an object in D is to have a pointer to the object (a
>> root) that the GC knows about that is not within a GC allocated object;
>> i.e. that root is on the stack, in static data, or is in some other
>> memory like malloc'd data.
>>
>> Java's JNI interface requires explicit pinning, but this is incompatible
>> with D's desire for easy interoperation with C.
>
> Right - thanks for the hint!
>
> That would leave the following rules for real-time audio code in D:
>
> a) Never allocate memory within the audio thread (be aware of library code or
> language intrinsics that may internally allocate memory)
> -> that way, the GC will never be invoked from the audio thread
>
> b) Make sure that the audio thread is not registered with the GC
> -> that way, the GC running in any thread, will not stall the GC
>
> c) Make sure that any heap allocated memory that is used by the audio thread is
> also referenced from outside the audio-thread by pointers that are not located
> inside GC controlled objects.
> -> that way memory is guaranteed not to be moved or deallocated by the GC, even
> if the audio-thread itself modifies pointers while the GC is running
>
> By following these rules, the D language should be as safe for of hard real-time
> requirements as C or any other language.
>
> Beware that all this does not really cover the initial case of this thread: I am
> talking of a setup where the GC is running in a different non-real-time thread.
> This approach allows full use of the regular library, as long as you keep memory
> setup and object creation out of the RT thread.
>

These are great rules. I need to pull this all together into a how-to article.