Re: Pausing an NSThread
Re: Pausing an NSThread
- Subject: Re: Pausing an NSThread
- From: Ron Fleckner <email@hidden>
- Date: Sun, 8 Nov 2009 20:37:47 +1100
On 08/11/2009, at 4:34 PM, Greg Guerin wrote:
Ron Fleckner wrote:
I've finally worked out a way to pause a thread and would like to
know if what I'm doing is dangerous or bad or...?
Exactly what problem are you trying to solve?
Pausing a thread is always potentially dangerous. Any locks or
@synchronized blocks acquired before reaching the pause-point will
still be held by the paused thread. That means any other threads
waiting for those locks will continue waiting. And if one of those
threads happens to be involved with other locks related to whoever
initiated the pause, then you have deadlock.
It's precisely this potential deadlock that caused Java's suspend()
method to be deprecated some time ago.
http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html
Please read that, then explain what problem you're trying to solve
by pausing a thread, or using a lock.
I assume it has something to do with your comment "// Do some stuff
with strings from the array and send the strings to a text view on
the main window", but without the full explanation, it means
nothing. It's about as meaningful as saying "I can call spirits
from the vasty deep", without giving the incantation, what you will
bid them do, or whether they will come when you do call for them.
-- GG
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
_______________________________________________
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