Re: NSRunloop performSelector needs CFRunLoopWakeUp ?
Re: NSRunloop performSelector needs CFRunLoopWakeUp ?
- Subject: Re: NSRunloop performSelector needs CFRunLoopWakeUp ?
- From: Michael Ash <email@hidden>
- Date: Mon, 26 Jan 2009 01:06:19 -0500
On Sun, Jan 25, 2009 at 12:47 PM, David Hoerl <email@hidden> wrote:
> Thanks to those who have posted on this, and suggested workarounds. However,
> in a simple non-threaded app, this call should work, no? And perhaps the 0
> time timer would also suffer the same fate.
Well as I said, the documentation says that it schedules your selector
for the next runloop pass, but it doesn't say anything about making
that pass actually happen in a timely fashion. A timer will not suffer
the same fate because a timer explicitly wakes up the runloop and
forces it to actually run when the time comes.
> PS: well, I re-read the Threading Programming Guide, and I saw
> "performSelectorOnMainThread", so tried it in my demo project. Bingo, it
> works as expected:
>
> [self performSelectorOnMainThread:@selector(getNextTask) withObject:nil
> waitUntilDone:NO];
>
> Also, this worked too:
>
> [self performSelector:@selector(getNextFrame) withObject:nil
> afterDelay:0.0];
>
> Both of these methods essentially queue the selector so it will be sent
> during the next run loop cycle, and NOT cause it to be executed immediately.
> It would appear that both are thread safe too.
They are thread safe, but the second one won't do what you expect in a
secondary thread. It will schedule the selector on the secondary
thread's runloop, not the main thread's runloop. But of course since
you're not multithreaded (my comment on that was way off-base due to
misreading your original post) it's not important.
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden