Re: Thread Cancelation
Re: Thread Cancelation
- Subject: Re: Thread Cancelation
- From: Nicko van Someren <email@hidden>
- Date: Fri, 29 Oct 2004 20:16:52 +0100
On 29 Oct 2004, at 19:24, John Stiles wrote:
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.
More generally, if you really really need to be able to clobber a
thread of execution without regard for its state then you should
consider hiving it off to a new process. That way the OS will be able
to close open files, free memory and generally clear up the mess that
you left.
On Oct 29, 2004, at 11:01 AM, Benjohn wrote:
...
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.
On Unix all the sleeping, blocking IO and waiting operations will
return an error if a signal is raised and handled while the call is in
progress. Therefore for the cases you list above your best bet is to
set up a signal handler that sets a self-termination flag and returns.
Then you can check this flag periodically within the thread you may
wish to kill and have the code exit cleanly when signalled to do so.
Nicko
_______________________________________________
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