Re: scheduling a block from a render callback
Re: scheduling a block from a render callback
- Subject: Re: scheduling a block from a render callback
- From: Ross Bencina <email@hidden>
- Date: Wed, 15 Jan 2014 14:26:37 +1100
On 15/01/2014 1:42 PM, Kyle Sluder wrote:
That assumes that constructing a block is real-time safe. It
probably isn't.
>
It makes no such assumption. AddNotificationHandler would be called
from the non-realtime-thread. PostNotification would be called from
the realtime thread; this function would perform a modicum of
realtime-thread-safe work to cause a non-realtime thread to submit
the registered block to its corresponding dispatch queue.
Fair enough.
It kind of defeats the purpose of using a closure if you can't use it to
pass data from the (notifying) context though.
If it were me I'd prefer something like an asynchronous RPC -- which is
effectively what you get if you use dispatch_async and block creation.
In AudioMulch I have a mechanism like this where function pointers and
parameters get pushed onto a lock free queue. I think you can probably
build a mechanism like this with blocks too. dispatch_async moves the
block data to the heap (hence malloc gets involved), but a custom
lock-free queue could move the block into a ringbuffer.
Did I post this already:
http://www.cocoawithlove.com/2009/10/how-blocks-are-implemented-and.html
Of course it's better to ween yourself off Objective-C for real-time
code. Objective-C is just another one of Apple's vendor-lock-in mechanisms.
Ross.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden