Re: Termination of threads.
Re: Termination of threads.
- Subject: Re: Termination of threads.
- From: Mike Shields <email@hidden>
- Date: Fri, 8 Feb 2002 19:25:30 -0700
On Friday, February 8, 2002, at 04:37 PM, email@hidden wrote:
[snip]
Yup, that's basically the way to do it.
I can say that for something like this, a full DO implementation isn't
needed. If you already have that, then that's fine, use it. But if you
need to fire off a thread to do come computation and don't need it to
update the UI directly, then not using DO works just as well (you'd
just use NSLocks to synchronize).
The problem with calling +exit (or if there was one -exit) is that
those calls stop the thread right then and there. No cleanup, nothing
else is called - so if you have resources allocated, they just got
leaked. Pthreads has pthread_cancel/pthread_testcancel which helps
with this, but there are still issues with system calls that can be
cancelled, etc. In my threads programming, I've found it easier and
less complicated to have my own cancel/abort/stop strategy worked out
specific to that thread and what it's doing.
True, there can be leaking and cleanup. What is the problem of
attaching a delegate method to a thread that will do the cleanup for
the thread?
Well the problem is there isn't one :-). Plus while a thread is an
object in the Cocoa sense, underneath, it's just a pthread. So when exit
is called, that in turn calls pthread_exit which cleans up the thread's
stack, etc. I guess there's the possibility of using the
NSThreadWillExitNotification to do some cleanup work for you, but I'm
not sure what that would buy you.
The thing is, and I had this problem initially, is that a thread (as in
NSThread) isn't an object you ever really get an instance of. So
thinking about a thread as an object is really false. It's a way to run
code from other objects in a separate task space. Notice that the only
instance method is -threadDictionary, and the only way to get a thread
instance is to ask for +currentThread, which as you can guess from the
name is only useful in side of a thread context itself (calling that
from the main thread will get you the main thread).
So you should really concern yourself with controlling the object you
pass into +detachNewThreadSelector:toTarget:withObject: and not worry
that it is running in a thread (heck maybe one day you'd make them work
using NSTimers or something else) - this is from the caller's side mind
you, the object itself would need to know this for locking purposes.
It might be a useful exercise to come up with a new thread class where
you could name threads and then look them up through (and obtain that
instance) a class method to control them (killing them, changing
priorities, etc).
Mike
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.