On Mon, Jul 26, 2010 at 9:27 AM, Charlie Dickman <3tothe...@comcast.net> wrote: > As long as the NSTimer firing interval is sufficiently small the NSTimer can > be used. If the run loop is stalled for any "significant: time _all_ timers > will be inaccurate to some degree.
This is untrue. mach_absolute_time is the kernel's timekeeping mechanism. It is not susceptible to runloop stalling or any stalling for that matter, short of a hardware failure or a bug in the kernel. NSTimer can't fire at a rate beyond a certain threshold. On the main runloop, I believe this will wind up being somewhere around one thread quantum because the main runloop is responsible for fetching events from Quartz, which would most likely involve taking a lock and thus waiting for WindowServer to get scheduled on the CPU. And then of course there's all manner of clock drift on a multicore machine like any Mac sold in the past few years; sometimes threads might execute on different cores, sometimes on the same core, and the ordering thereof affects how frequently the runloop can wake. All of this assumes that the stall doesn't happen for more than one timer duration, and to make matters worse, doesn't solve the OP's problem at all, since NSTimer isn't going to fire during machine sleep! --Kyle Sluder _______________________________________________ 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
