As others have noted, NSTimers are bound by the runloops they operate
in. Though you can always spawn a dedicated thread, create a run
loop, add your timer, and then go; since nothing else is in the
runloop, the latency should be quite low. I'd try that first, and see
if it meets your needs.
Failing that, you can move down to a lower level - one approach I've
seen used successfully in several latency-sensitive apps is
pthread_cond_timedwait (on a condition that never necessarily gets
signalled, though that can be a convenient way to cancel your timer).
Kind of obtuse, but it's highly portable and I don't know of a
canonical "wait" function of comparable precision. It's still a "wait
for duration" rather than "wait for time" though; I don't know off
hand of any way to [reliably] do the latter.
setitimer was suggested, but personally I try to avoid signals
wherever possible, plus:
a) You can only have one (of each of the three types, but nonetheless).
b) It's formally defined as having "tick" resolution, which doesn't
strictly make sense on Mac OS X but is in any case orders of magnitude
above microseconds. I think on Mac OS X it actually provides
microsecond resolution, but that's not something you can technically
rely on (especially if you're writing portable code).
If you have a dedicated thread you can also raise its priority or try
making it real-time, to give yourself a further edge.
Wade
P.S. For completeness I should mention of course nanosleep, but I
don't know of its precision and in any case it can be interrupted by
signals, which makes it more difficult to use than you'd expect.
_______________________________________________
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
