Re: Termination of threads.
Re: Termination of threads.
- Subject: Re: Termination of threads.
- From: Raphael Sebbe <email@hidden>
- Date: Sat, 9 Feb 2002 10:25:50 +0100
In my experience, it is much safer to have some data associated with
each thread, that can be modified from the outside (read other threads,
in a synchronized way), and that the thread handles its termination
itself from what is inside that data. This allows better cleanup and
re-synchronizing (if needed) with the main thread.
I somehow remember problems using pthread cancelling on OS X, though
this perhaps has been solved since. If you are using NSThread, I would
not recommend mixing the APIs - pthreads and Foundation - (at least when
it comes to starting and terminating...).
HTH,
Raphael
On Saturday, February 9, 2002, at 03:25 AM, Mike Shields wrote:
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.
_______________________________________________
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.