A few comments about D

[Rainer Schuetze]

On 23.08.2011 20:48, Andrej Mitrovic wrote:
> On 8/23/11, Nick Sabalausky<a at 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.