> On Mon, 2010/07/26, Kyle Sluder <kyle.slu...@gmail.com> wrote:
>> 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...
Whatever happened to the pre-emptive processing we were
supposed to be getting with OS X?
If it were pre-emptive, you'd interrupt and then it
would happen, not twiddle around until the next time
around a run-loop and sifting through a queue.
In this context, you'd set the timer, and when the
time was up, control would switch to where you'd told
it to when you set up the timer.
Boom. Ditto with a user-interrupt.
Only if there were a conflict -- essentially two
interrupts at once, within less than a millisecond
of each other -- would any queueing, stacking, etc.,
come into play.
Whatever happened to hardware monitoring and control
of the CPU (core)?
_______________________________________________
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
