A few comments about D

Timon Gehr timon.gehr at gmx.ch
Tue Aug 23 16:19:38 PDT 2011


On 08/24/2011 12:24 AM, Rainer Schuetze wrote:
>
> 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.

Basically, afaik you can already get that now. It suffices not to 
register the new thread with the GC. (I don't know if core does provide 
an interface for this) The thread then has to use manual memory management.

>
> 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.


More information about the Digitalmars-d mailing list