On 23.08.2011 20:48, Andrej Mitrovic wrote:
On 8/23/11, Nick Sabalausky<a@a.a> wrote:
I certainly hope so. That's desperately needed for certain domains.
It would be super-useful for audio programming. If someone were to
write a VST audio plugin for use in some music sequencer (Ableton
Live, Steinberg Cubase, etc), they would have to guarantee there are
*zero* pauses while the plugin is processing audio. It /might/ be ok
to do any collections when the plugin is idling, and there's a way to
check that in the VST SDK. But the biggest concern to me are implicit
calls to GC due to e.g. array concatenation.
I was planning on making a D wrapper library for the VST protocol, but
until this is sorted out I think I'll just stay away from it for now.
I don't want to have fingers pointed at me when someone writes a VST
plug that ends up crashing some user's sequencer due to a GC
collection (and more likely than not the companies who make sequencers
would get fingers pointed at, which is bad).
A way to deal with this could be done in the runtime library, allowing
to set a flag for the real time thread, that excludes it from being
suspended in a garbage collection. It is then the responsiblity of the
developer to ensure that any GC data used in the realtime thread is also
referenced elsewhere.
Another flag might cause any (possibly blocking) GC calls to bail out if
it is called from within this thread. This is no perfect compiler
guarantee, but at least a runtime check for the thread not depending on
a GC lock.
