On Tuesday 21 December 2010 11:55:23 boost-users-request@lists.boost.org wrote:
Hmm, looking into thread.cpp implementation of thread_proxy (callback function for pthread_create()) and boost::thread::join I do not see how this join implementation would work with any abnormal thread termination. In thread.cpp boost::thread::join waits the thread termination on line: local_thread_info->done_condition.wait(lock);
The lock gets signaled only at end of thread_proxy(), which is reached only if the user thread routine does "return" or is interrupted with boost::thread means. pthread_exit(), as well as any other emergency termination does only stack unwinding (on most but not all systems), so done_condition is simply never signaled in these circumstances. To be correct the thread_proxy() should have installed cleanup routine with pthread_cleanup_push() and, to be sure, have an local object which destructor would signal done_condition as well, but I do not see it in boost::thread code.
Bogdan, when you said, the test program works for you - did you means it does return with status 0? If so, I wonder, which way the execution goes in your thread_proxy implementation - can you please debug it a little if you have some time? To build debug version of boost you need to add "variant=debug" option to bjam. I tried the same test program on ubuntu 10.04 TLS with gcc 4.4.3 and boost 1.40 - the same result as with latest boost: it freezes in boost::thread::join() on condition.wait().
Hi pthread_exit() is used to pass data to the parent thread at exit. pthread_join() should receive this data to its second parameter. I will try to have a closer look, but I doubt that boost doesn't handle correctly such situation. regards Bogdan