On 08-Nov-2009, at 5:37 PM, Ron Fleckner wrote:
Hi Greg, thanks for the link.
I think I've learned that the effect of pausing a thread can be just
as easily and more safely achieved by simply stopping it depending
on a BOOL on the main thread. Yes? So, in my situation, I would
send the new worker thread at creation an ns collection of some
sort, maybe a dictionary, which contains pointers to my array of
data and also the index at which to start processing it.
BTW, if you're interested, the work in "// Do some stuff..." is
creating, via mutable attributed strings, an attributed string for a
text view on the main window. At the end of each run through a
loop, it does [self performSelectorOnMainThread:withObject:wait:]
which blits the text to the text view. I _think_ need a new thread
to do this, which allows the user to see some action from this
potentially long process (length varies according to the number of
installed fonts which is in some cases quite high).
Maybe there's a better way?
Anyway, I do appreciate your comments. Dave DeLong's mini tutorial
about locks points out that I do need some help and your link helped
as well. Now I will do as Kyle suggests and do some more general
reading (than the docs) about threading before I continue much
further. I can still 'experiment' on myself in the meantime.
Ron
Why pause it? Why not just let it finish and next time you have
something to do, make another thread to do that? Much less work there.
Or look at NSOperation/NSOperationQueue which absolves you of the need
to care about threads, it's done for you (and I believe makes use of
Grand Central Dispatch on current versions of OSX). Just package up
whatever it is you need to do and send it off and some thread
somewhere will do it for you.
If you have a 'producer-consumer' type problem, where your thread is
waiting for more data from something else, then go look up producer-
consumer and see how to implement that with NSCondtion .. or .. use
NSOperationQueue if each 'operation' is sufficiently standalone (ie
you're not keeping state in the object you're running on your thread),
just have the main routine code throw an operation on the queue when
it wants it.
Or if you just want a thing which happens on a regular (timer) basis,
but you want that thing to be on a separate thread for some reason,
run a runloop on the thread, set up an NSTimer to fire and do the
thing you do when it fires, the runloop will take care of suspending
the thread until the timer fires.
It is hard to think of any instance in which sleeping a thread for
1/10th of a second and then polling is the right thing to do.
_______________________________________________
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
