Re: How to properly exit a thread?
- From: Chris Vine <chris cvine freeserve co uk>
- To: gtkmm-list gnome org
- Cc:
- Subject: Re: How to properly exit a thread?
- Date: Sun, 14 May 2006 22:22:42 +0100
On Sunday 14 May 2006 06:10, Xiangfei Jia wrote:
> I created a thread like this:
>
> Glib::Thread *const read = Glib::Thread::create(sigc::mem_fun(node,
> &FrameNode::read_new_data), false);
>
> Sometimes, when I exit from my program I got this error message:
> GThread-ERROR **: file gthread-posix.c: line 247 (): error 'Device or
> resource busy' during 'pthread_cond_destroy ((pthread_cond_t *) cond)'
> aborting...
> Aborted
>
>
> I looked at the Glib reference, I found out I should use
>
> throw Glib::Thread::Exit
> <http://www.gtkmm.org/docs/glibmm-2.4/docs/reference/html/classGlib_1_1Thre
>ad_1_1Exit.html>();
>
> to exit my thread. But I don't really know how to use this properly. Can
> anyone tell me how to use it please!!!!!
Glib::Thread::Exit is an exception which can be thrown in a thread to cause
the thread to terminate itself, as an alternative to calling g_thread_exit().
g_thread_exit() may or may not unwind the stack of the terminating thread
when it is called - that depends on the underlying implementation (if the
underlying threading system is the NPTL implementation of pthreads it will,
if it is the linuxthreads implementation of pthreads or, I believe, Windows
threads it will not). The idea behind Glib::Thread::Exit is to ensure stack
unwinding, so that local objects having non-trivial destructors are correctly
destroyed, by propagating the exception through the stack until being caught
by the Glib::Thread implementation just before the thread terminates itself.
You should not normally try to catch Glib::Thread::Exit yourself (you should
only do so if you want to check whether you want to proceed with thread
termination part-way through the stack unwinding).
You do not need to bother with Glib::Thread::Exit (or g_thread_exit() or
pthread_exit()) if your thread terminates "naturally" by the slot function
called in Glib::Thread::create() (in your case FrameNode::read_new_data())
returning. It is a mechanism to procure "premature" termination.
The error you report appears to indicate that a thread was waiting on a
condition variable when the condition variable was destroyed (probably when
the Glib::Cond object concerned went out of scope causing its destructor to
call pthread_cond_destroy()). That indicates a logic error somewhere in your
code, and according to the POSIX standard it also gives rise to undefined
behaviour.
Chris
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]