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: Kyle Sluder <email@hidden>
- Date: Tue, 14 Jan 2014 23:51:34 -0800
On Jan 14, 2014, at 7:26 PM, Ross Bencina <email@hidden> wrote:
>
> 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.
The purpose of defining the API to only take a non-pointer argument is to discourage use of any realtime-unsafe practices. Adding a context pointer would just invite use of malloc() among the very people who need a guiding API the most.
As for closures, they never close over the *invocation*, so I don't see how the fact that my API takes a closure rather than a function pointer is relevant at all. In fact, since libdispatch accepts function pointers wherever it accepts blocks, I could have defined the API entirely in terms of functions with no loss of generality.
>
> 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.
You say this in a thread about Apple's proprietary and platform-specific audio APIs…
--Kyle Sluder
_______________________________________________
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