On Jul 22, 2012, at 9:24 PM, Jens Alfke wrote:
> On Jul 22, 2012, at 6:43 PM, Jay Reynolds Freeman
> <jay_reynolds_free...@mac.com> wrote:
>
>> Since my app has nothing to do while waiting for the sound to play, a
>> polling loop on "isPlaying" is actually a good deal less code (only two
>> lines) than setting up a delegate with "-sound:didFinishPlaying" implemented.
>
> It may be less code, but it's bad practice. It locks up the thread,
> preventing the runloop from performing other activities, and it consumes a
> lot of CPU unless you put in a sleep call.
>
> If you really have to block, use a loop that spins the runloop, like this:
>
> while (!readyToStop()) {
> if (![[NSRunLoop currentRunLoop] runMode: someCustomRunLoopMode
> beforeDate: [NSDate distantFuture]])
> break;
> }
Actually, this defeats the purpose. By specifying a custom run loop mode,
rather than the default run loop mode, you are *not* providing an opportunity
for any framework run loop sources to be serviced. They could not possibly be
scheduled on your custom run loop mode.
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
