Re: How to properly exit a thread?



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]