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.
