Re: delay function
Re: delay function
- Subject: Re: delay function
- From: Thomas Davie <email@hidden>
- Date: Wed, 8 Dec 2004 04:39:30 +0000
On 8 Dec 2004, at 04:29, Brendan Younger wrote:
On Dec 7, 2004, at 9:25 PM, Ricky Sharp wrote:
On Dec 7, 2004, at 9:18 PM, Thomas Davie wrote:
On 8 Dec 2004, at 02:43, Ricky Sharp wrote:
I current have it set to 50 ms which would be just over 6 ticks. I
have yet to fine-tune this. At 8-ticks it seems a bit too high
when comparing it to what the built-in widgets do (e.g. NSButton).
A quick note - you're much better off using an NSTimer to fire an
event when you need to unhighlight your control – that way only the
threads that depend on that control block and the rest of your
computation continues – much better for multitasking.
That's a good tip. I'll definitely revisit this code later to ensure
it's a good citizen. I will especially need it in an upcoming title
which will be using threads to run the AI portion of a game.
While I would agree that a timer is much better general practice for
this sort of thing, you need to remember that NSRunLoop is not exactly
fit for real-time processing. In fact, NSRunLoop will often "cheat"
with timer fire dates and fire just a little early to make sure that
your callback will be called in time. For a UI element, you most
certainly do not want the highlight delay to be variable, which it
certainly will if you use NSTimers. Using +[NSThread sleepUntilDate:]
is the correct call in this case since it will NOT block other
threads, even though sleep() and usleep() might. In fact, +[NSTimer
sleepUntilDate:] actually calls the Mach function thread_switch()
underneath (curse pthreads for not having a pthread_sleep()
function!). If you're curious, add a breakpoint on _NSMilliSleep()
(I'm pretty sure that's the correct name) which you can see in the
disassembly just calls thread_switch(). One final thing to note is
that Mach does not promise that it will be able to sleep a thread for
any amount of time; it may well be that every other thread in the
system is blocked on some resource, but I've yet to actually see this
in practice.
Yep, certainly, sorry, I wasn't trying to imply that the NSTimer
version was better than the NSThread version... And I was unaware of
the issue you highlight above. I''m fairly sure (or would hope that)
though that anyone who's writing a real-time critical application would
have enough sense to realise that a weakly typed, relatively
imprecisely defined, badly constrained, overly high level language like
Obj-C is not the write thing to write their app in. And go away and
use Hume or Ada. And if they don't well... they should read this
thread an think again about what they're doing ;).
Bob
--
What is the internet?
It's the largest equivalence class in the reflexive transitive
symmetric closure of the relationship "can be reached by an IP packet
from". -- Seth Breidbart
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden