GNOME.org
 

Re: is it possible to 'kill' a thread?

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]