is d-runtime non-gc safe?

[Norbert Nemec]

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.