Re: Thread Cancelation
Re: Thread Cancelation
- Subject: Re: Thread Cancelation
- From: John Stiles <email@hidden>
- Date: Fri, 29 Oct 2004 11:24:33 -0700
In what instances are you actually "canceling" threads?
It's not possible to just whack a thread arbitrarily, since that could
leave the application in an unstable state. (Imagine the thread was in
the middle of a call to malloc when you killed it! Ouch.)
But it's certainly possible to make a little bit of code which can
"signal" to the thread that it should consider wrapping things up.
That's a viable option that's easy to implement.
It really depends on how you're using the functionality. If you need it
to work in the general case, where you want to write a bunch of code
and be able to kill it at a moment's notice, then I don't see how that
could be expected to work on any OS. What if the thread had just
allocated a big chunk of memory--are you just going to leak it? What if
it has a file handle open? Etc. Axing a thread without going through
the proper cleanup seems like a bad way to code.
On Oct 29, 2004, at 11:01 AM, Benjohn wrote:
We've just started porting our .Net application over to OS X.
We have a thread abstraction which assumes it is possible to cancel a
thread. If a thread is sleeping, or waiting on a semaphore or mutex,
it will gracefully terminate when asked. Otherwise, the thread will
cancel itself when it is prepared to do so.
In trying to implement our thread abstraction in OS X, we're
encountering "some trouble". From what we've found so far, it seems
that neither NSThread, nor the p_thread implementation in OS X, will
meet our requirements.
I'd appreciate it if someone could confirm that the thread
implementations in OS X do not allow cancelling of a thread that is
waiting on a mutex or semaphore, or is sleeping; I'm reluctant to
undertake a considerable rewrite, or tender my resignation, if it is
not entirely necessary.
Thanks very much for your time,
Benjohn Barnes
_______________________________________________
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
_______________________________________________
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