Re: is it possible to 'kill' a thread?
- From: Paul Davis <pjdavis engineering uiowa edu>
- To: gtkmm-list gnome org
- Subject: Re: is it possible to 'kill' a thread?
- Date: Tue, 17 Jan 2006 02:32:59 -0600
Ed Leaver wrote:
On Mon, 2006-01-16 at 13:38, Chris Vine wrote:
/On Monday 16 January 2006 16:00, B.Hakvoort wrote:
Hi,
I was wondering if it's possible to end a thread from OUTSIDE that
thread. I have a thread which executes an un-interruptable function and
i'd like to end that execution whenever a user presses the 'cancel'
button.
I did some searching and found Glib::Thread::Exit, but i'm not sure how
it can be usefull in this situation.
Any insights in how to accomplish this the 'right' way?
You can't with GThread/Glib::Thread. However, if you know that pthreads is
the underlying implementation, you can use pthread_cancel(). I think Windows
has something similar.
Note that pthread_cancel() is a C function. When used in a program written
with C++, it is implementation defined whether the destructors of local
(automatic) objects are invoked (with linuxthreads they are not, but with
NPTL they are - and the same would apply to a call to g_thread_exit()).
Accordingly it is best to make no assumptions, and to choose the cancelation
point (with pthread_setcancelstate()) for a time when there are only built-in
types in local scope, and to use pthread_cleanup_push()/pthread_cleanup_pop()
for cleanup of other resources.
An alternative is to signal the thread concerned so that it will call
g_thread_exit() or throw Glib::Thread::Exit. However if you do this via the
main program loop (say, with a Glib::Dispatcher object) then the signalling
thread has no control over the time when the other thread will receive the
signal. However it becomes very easy for the receiving thread to arrange a
suitable time to commit suicide which cleans up properly when it receives the
signal (so that g_thread_exit() will be fine). But that in turn means that
the receiving thread cannot be in a blocking system function, and enabling
the use of blocking system calls is quite a common reason for using separate
threads in the first place. In that case you will have to call
pthread_cancel() from the other thread. Happily, in POSIX all blocking
system calls are cancelation points.
/
Another alternative might be to share a message object between the two
threads: the master thread sets a flag in the message object (mutexes
are your friend!) when the user wants the slave thread to terminate,
and the slave thread periodically at its convenience checks the
message object's flags to determine how it should continue, or
terminate. Again, be sure to set mutexes around the flag reads and
writes.
Note: although I once wrote such a ThreadInfo class to work with Glib
threads, I never tested it to the point I could claim it was
bombproof. YMMV :-)
Cancelling a thread is a no no. The general rule of thumb is to do what
Ed here is saying. You write your worker thread so that it checks some
sort of status flag. This solves a couple of problems, first and
foremost, its implementation independant ( not to say that the actual
calls are, unless you use something like Glib::Thread ; I imagine, I've
only used pthreads cause like any normal *nix developer, I generally
shun windows. </rant> )
Anyway, that being said, if you do use something like pthreads, there is
an alternative method. pthread_signal is a way to signal threads. It
works quite a bit like normal process signaling, but on a per thread
basis. You can setup your thread signal masks on a per thread basis,
and then send messages via signals in this manner. There are some
caveats. First, you're gonna need a new enough implementation of
pthreads. Second, but really part of the first, this is going to limit
portability even between *nix distros. I do alot of Tru64 / FC4
development. Its been awhile so I can't remember if Tru64 supports
pthread_signal.
Anyway, I just realized I probably rambled along for a bit too long.
Basically, write your threads to check some sort of shared memory. You
can do this in quite a few ways. The easiest for me was writing objects
that synchronize themselves and pass the pointer when creating the
thread. Its pretty fun stuff once you get the hang of it, but it does
take awhile to get the hang of some of the more difficult multithreaded
concepts.
Anyway, hope that helps, a good reference where I learned alot about
this sort of thing is "Multithread Programming with Pthreads" by Lewis
and Berg. It focuses on implementing threads with the pthread api, but
describes when other api's are a bit different. And its all in all a
good read for the basic ideas of MP, not just about pthreads.
Oh, and, the type of problem you'd be interesting in googling about is
called producer-consumer model/example/common name in books.
Basically, a producer creates a message for a consumer to eat. My
analogies are getting worse.
googling:
http://java.sun.com/docs/books/tutorial/essential/threads/synchronization.html
http://cne.gmu.edu/modules/ipc/aqua/producer.html
--obviously just some light reading on the problem, but you should be
able to find loads on the subject, its a fairly common model.
Cheers,
Paul
/
/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]