On Aug 5, 2010, at 10:27 AM, Jeff Johnson wrote: > Why do you just set a short timeout rather than distantFuture? That's why I > usually do.
Because polling is bad. More specifically, if you choose a short timeout, this loop consumes CPU time and keeps bits of your code hot in the VM cache. But if you choose a longer timeout, it can take longer than necessary for this loop to exit, which slows down the caller. On Aug 5, 2010, at 10:29 AM, Jean-Daniel Dupas wrote: > CFRunLoopWakeUp([[NSRunLoop currentRunLoop ] getCFRunLoop]) I tried that (although it’s simpler to use CFRunLoopGetCurrent!), but it appeared to be a no-op. > CFRunLoopStop([[NSRunLoop currentRunLoop ] getCFRunLoop]) This is what I ended up using, although it’s a kludge because it requires that the method that handles the notification know whether or not the caller is running in synchronous mode (I added an instance variable flag for this.) On Aug 5, 2010, at 11:10 AM, Ken Thomases wrote: > Since you're waiting on an NSTask to finish, is there a reason you're not > using -[NSTask waitUntilExit]? Because the code that runs that NSTask is buried in another class, which comes from an external project (Google’s Keystone auto-updater library) which I really don’t want to start messing with. —Jens_______________________________________________ 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
