I'm pondering the viability of using ObjC blocks in a realtime Core Audio thread context.
I go to extensive measures to avoid any kind of blocking code in the Core Audio thread, and that includes avoiding making Objective-C calls, as the message sending system does do some internal locking, and thus could block the thread.
I'm wondering if this also applies to the use of blocks - assuming of course, the implementation contained within the block itself doesn't do any blocking or Objective-C method calls.
Does performing a block...block? Does it use an internal mutex, which could end up holding up the realtime thread? Is there any other reason to avoid blocks in a realtime context?
Many thanks,
Michael
-- Michael Tyson | atastypixel.com
Live, app-to-app audio streaming is coming soon.
Don't want to miss our launch? Then sign up here: http://audiob.us
A block compiles down to a single method call. Copying a block to the heap
will copy any referenced variables, so if it captures an ObjC object you'd
need to ensure that object's -copy implementation didn't block. But calling
a block itself just compiles down to a call instruction, so no blocking or
locking behavior there.
Sent from my iPhone
On 2012-08-31, at 8:41 AM, Michael Tyson <mich...@atastypixel.com> wrote:
Hello,
I'm pondering the viability of using ObjC blocks in a realtime Core Audio
thread context.
I go to extensive measures to avoid any kind of blocking code in the Core
Audio thread, and that includes avoiding making Objective-C calls, as the
message sending system does do some internal locking, and thus could block
the thread.
I'm wondering if this also applies to the use of blocks - assuming of
course, the implementation contained within the block itself doesn't do any
blocking or Objective-C method calls.
Does performing a block...block? Does it use an internal mutex, which
could end up holding up the realtime thread? Is there any other reason to
avoid blocks in a realtime context?
Many thanks,
Michael
-- Michael Tyson | atastypixel.com
Live, app-to-app audio streaming is coming soon.
Don't want to miss our launch? Then sign up here: http://audiob.us
So, in that case, as long as the actual management of the block's lifespan (copy, release, etc - which may do mutex stuff) is performed outside the realtime context, the block perform call itself should presumably be perfectly fine, in the context of Apple's "don't block" guidelines.
Thanks heaps,
Michael
-- Michael Tyson | atastypixel.com
Live, app-to-app audio streaming is coming soon.
Don't want to miss our launch? Then sign up here: http://audiob.us
On 31 Aug 2012, at 13:44, Jim Dovey <jimdo...@gmail.com> wrote:
> A block compiles down to a single method call. Copying a block to the heap will copy any referenced variables, so if it captures an ObjC object you'd need to ensure that object's -copy implementation didn't block. But calling a block itself just compiles down to a call instruction, so no blocking or locking behavior there.
> Sent from my iPhone
> On 2012-08-31, at 8:41 AM, Michael Tyson <mich...@atastypixel.com> wrote:
>> Hello,
>> I'm pondering the viability of using ObjC blocks in a realtime Core Audio thread context.
>> I go to extensive measures to avoid any kind of blocking code in the Core Audio thread, and that includes avoiding making Objective-C calls, as the message sending system does do some internal locking, and thus could block the thread.
>> I'm wondering if this also applies to the use of blocks - assuming of course, the implementation contained within the block itself doesn't do any blocking or Objective-C method calls.
>> Does performing a block...block? Does it use an internal mutex, which could end up holding up the realtime thread? Is there any other reason to avoid blocks in a realtime context?
>> Many thanks,
>> Michael
>> -- >> Michael Tyson | atastypixel.com
>> Live, app-to-app audio streaming is coming soon.
>> Don't want to miss our launch? Then sign up here: http://audiob.us
> A block compiles down to a single method call. Copying a block to the heap will copy any referenced variables, so if it captures an ObjC object you'd need to ensure that object's -copy implementation didn't block. But calling a block itself just compiles down to a call instruction, so no blocking or locking behavior there.
> Sent from my iPhone
> On 2012-08-31, at 8:41 AM, Michael Tyson <mich...@atastypixel.com> wrote:
>> Hello,
>> I'm pondering the viability of using ObjC blocks in a realtime Core Audio thread context.
>> I go to extensive measures to avoid any kind of blocking code in the Core Audio thread, and that includes avoiding making Objective-C calls, as the message sending system does do some internal locking, and thus could block the thread.
>> I'm wondering if this also applies to the use of blocks - assuming of course, the implementation contained within the block itself doesn't do any blocking or Objective-C method calls.
>> Does performing a block...block? Does it use an internal mutex, which could end up holding up the realtime thread? Is there any other reason to avoid blocks in a realtime context?
>> Many thanks,
>> Michael
>> -- >> Michael Tyson | atastypixel.com
>> Live, app-to-app audio streaming is coming soon.
>> Don't want to miss our launch? Then sign up here: http://audiob.us
On Aug 31, 2012, at 8:44 AM, Jim Dovey <jimdo...@gmail.com> wrote:
> A block compiles down to a single method call. Copying a block to the heap will copy any referenced variables, so if it captures an ObjC object you'd need to ensure that object's -copy implementation didn't block. But calling a block itself just compiles down to a call instruction, so no blocking or locking behavior there.
A block call is a single *function* call. When you write block(...), it compiles down to code that does block->implFptr(block, ...), where block is conceptually a struct, and implFptr is a member containing a function pointer to the block's actual code. Unlike ObjC method calls, there's no way this code can block short of the memory it depends on being paged out. (ObjC message sends can potentially take locks, although it's extremely rare.)
Copying a block in the render callback would be bad regardless, as the memory allocation alone is something you'd want to avoid. But assuming you copy it beforehand, it's perfectly safe to call as long as the contents are safe.
Lovely, thanks for the reassuring clarification, Mike. I've revised my implementation and it's working splendidly with blocks now.
(It's a mechanism I've build into my audio engine that allows me to synchronise between the Core Audio thread and other threads, without needing locks.) So:
For sending messages to the Core Audio thread, and
void AEAudioControllerSendAsynchronousMessageToMainThread(AEAudioController *audioController, AEAudioControllerMainThreadMessageHandler handler, void *userInfo,
int userInfoLength);
for sending messages back to the main thread; both based upon a lock-free circular buffer.
Working very nicely now with blocks - a lot easier than what I was doing before, which was using a C function pointer and userInfo, like the third method above.
On 31 Aug 2012, at 15:24, Michael Ash <michael....@gmail.com> wrote:
> On Aug 31, 2012, at 8:44 AM, Jim Dovey <jimdo...@gmail.com> wrote:
>> A block compiles down to a single method call. Copying a block to the heap will copy any referenced variables, so if it captures an ObjC object you'd need to ensure that object's -copy implementation didn't block. But calling a block itself just compiles down to a call instruction, so no blocking or locking behavior there.
> A block call is a single *function* call. When you write block(...), it compiles down to code that does block->implFptr(block, ...), where block is conceptually a struct, and implFptr is a member containing a function pointer to the block's actual code. Unlike ObjC method calls, there's no way this code can block short of the memory it depends on being paged out. (ObjC message sends can potentially take locks, although it's extremely rare.)
> Copying a block in the render callback would be bad regardless, as the memory allocation alone is something you'd want to avoid. But assuming you copy it beforehand, it's perfectly safe to call as long as the contents are safe.
