On Sat, Jan 24, 2009 at 11:07 PM, Adam R. Maxwell <amaxw...@mac.com> wrote: > > On Jan 24, 2009, at 10:18 PM, Michael Ash wrote: > >> On Sat, Jan 24, 2009 at 3:42 PM, David Hoerl <dho...@mac.com> wrote: >> > [...] > >>> The current app is single threaded. >>> >>> Can anyone shed any light on why the CFRunLoopWakeUp() call is necessary? >>> Is >>> there some other issue I'm missing? >> >> Look at the big master list of what Cocoa classes are thread safe: > > The OP wrote that his app is single threaded, so the lack of NSRunLoop > thread safety shouldn't be a problem. It sounds like the event loop is > blocking the runloop, so maybe posting a custom event would work as well as > tickling the runloop...but that's just a guess.
Man, missing one tiny sentence is enough to make a guy look like an idiot. Oh well, thanks for pointing it out. I think you're right about the event. Reading the documentation: "This method sets up a timer to perform the aSelector message on the current thread's run loop at the start of the next run loop iteration." I think the words "the next run loop iteration" are key here. It will invoke your method at the next run loop iteration... but it won't make that iteration happen any sooner! For what the OP wants, I think the best thing would be to just avoid that method. Use -performSelector:withObject:afterDelay: (with a 0 delay) or a non-repeating NSTimer (with a 0 interval). Mike _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
