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 <norb...@nemec-online.de> wrote: > On 04.12.2011 09:10, Marco Leise wrote: >> Am 03.12.2011, 19:47 Uhr, schrieb Andrej Mitrovic >> <andrej.mitrov...@gmail.com>: >> >>> On 12/3/11, Marco Leise <marco.le...@gmx.de> wrote: >>>> Am 03.12.2011, 19:05 Uhr, schrieb Andrej Mitrovic >>>> <andrej.mitrov...@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.
