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: Stéphane Letz <email@hidden>
- Date: Wed, 15 Jan 2014 09:06:14 +0100
Le 15 janv. 2014 à 08:51, email@hidden a écrit :
>
> Message: 9
> Date: Tue, 14 Jan 2014 23:51:34 -0800
> From: Kyle Sluder <email@hidden>
> To: Ross Bencina <email@hidden>
> Cc: "email@hidden API"
> <email@hidden>
> Subject: Re: scheduling a block from a render callback
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=utf-8
>
> 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
>
A far as I remember, Michael Tyson did implement something related to this question in TheAmazingAudioEngine ?
https://github.com/TheAmazingAudioEngine/TheAmazingAudioEngine
Maybe contacting Michael could help?
Stéphane Letz
_______________________________________________
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