Re: Thread Cancelation
Re: Thread Cancelation
- Subject: Re: Thread Cancelation
- From: p3consulting <email@hidden>
- Date: Sun, 31 Oct 2004 13:22:27 +0100
FYI
http://developer.apple.com/samplecode/SocketCancel/SocketCancel.html
"Description
SocketCancel is a sample that shows how to use safely cancel threads
that are blocked within BSD sockets calls. It uses a simple sockets
abstraction layer that wraps a non-blocking data socket, a UNIX domain
socket pair that's used to signal cancellation, and creative use of the
select system call. Requirements: Mac OS X Keywords: socket,
non-blocking, thread, cancel"
Pascal Pochet
email@hidden
----------------------------------
PGP
KeyID: 0x208C5DBF
Fingerprint: 9BFB 245C 5BFE 7F1D 64B7 C473 ABB3 4E83 208C 5DBF
Le oct. 29, 2004, à 21:16, Nicko van Someren a écrit :
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
_______________________________________________
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