Re: Thread Cancelation
Re: Thread Cancelation
- Subject: Re: Thread Cancelation
- From: Benjohn <email@hidden>
- Date: Mon, 1 Nov 2004 11:38:30 +0000
On 30 Oct 2004, at 01:57, email@hidden wrote:
On most threading implementations, canceling a thread is a bad idea.
If a thread is sleeping or waiting on a mutex, etc, what, exactly do
you expect to happen? What happens to any memory that code in that
thread allocated? What happens to resources that that thread my have a
lock on? What happens to objects that still have positive retain
counts?
These are all accounted for by POSIX with pthread cleanup handlers or
thread-specific memory.
*nods* I would expect the clean up handlers to throw an exception in to
the thread (when it's at a cancelation point, see:
http://tinyurl.com/3zate. I notice that pthread_mutex_lock() is not a
cancelation point, but it should still be possible to cancel when
waiting on a semaphore).
As we are coding in objective c++, and make a great deal of use of the
stack object idiom for handling resources, the exception would cause
all the thread's resources to be freed as it propagated through the
stack and caused it to unwind. :) This ought to all be quite simple,
and not the nightmare of catch blocks that it sounds like.
So - I'm pretty sure the principle is sound, and I'm pretty sure
p_threads ought to be able to do it.
Apparently, Darwin doesn't offer the full POSIX
functionality of pthread cancel states which means Darwin is deficient.
From an apple list posting (http://tinyurl.com/5rzae), the only cancel
points that seems to be supported are:
pthread_testcancel()
pthread_setcancelstate()
pthread_setcanceltype()
From the same article:
"All of the other cancellation points that are documented in Mac OS man
pages
and others that are also customary/required by the POSIX standard are
not
implemented to support cancellation.
I'd like a slightly more official statement of what the pthread
implementation does and doesn't do though; without that information, a
work around will be stabbing in the dark at available functionality.
If it is possible to cancel an arbitrary mach thread, then it should be
possible to cancel pthreads layered on top of them. The deficiency
lies in a number of syscalls which are not cancel-safe.
Maybe this will be fixed in the next release.
:) I hope so, we're hoping to release before Christmas though :)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden