Re: Tight loop processing
Re: Tight loop processing
- Subject: Re: Tight loop processing
- From: Wade Tregaskis <email@hidden>
- Date: Thu, 10 Apr 2008 14:13:12 -0700
Threads are almost always the right way to do what the OP wants. The
problem as was presented is that there's some work to do, which
happens to be dividable into N segments. There were no bounds placed
on how long it takes to run any individual segment. And even if there
were, they'd probably be wrong - just about anything your code does
can be delayed unexpectedly in weird and wonderful ways.
No, the correct approach is to do your work on a separate thread. In
Leopard you can send messages between threads trivially using
performSelector:onThread:withObject:waitUntilDone:, which makes it
very simple to tell your worker thread to stop, or send results &
status back to the main thread, etc.
It's worth doing this properly if only for the sake of learning how to
do it. Concurrency is the way of the future, like it or not, and
threads are the primary way to get that concurrency. They're more
resistant to numerous failure modes (such as unexpected blocking,
excessively long work periods, and more) and they scale better - you
can do other stuff, you could run two threads concurrently to do a
second set of work, etc. And, naturally, they give you performance
scaling that is potentially even better than linear.
Sorry if that all sounds a bit pious, but I personally feel it's
really important that people don't try to use crutches like timers or
delayed performs, that are only going to be a liability sooner or later.
Wade
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden