Sign in to follow this  

Boost.Thread zombies

This topic is 3780 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm creating a server process that will spawn multiple threads in response to events. I'm wanting to use Boost.Thread to do this, but I'm a bit nervous about how to handle things. If I create the thread by thread(func) and then let the thread object go out of scope, what will happen when the child thread finishes executing? Will it become a zombie process (on Linux), or what, since join was never called. Another thing I was looking at was using the thread_group, and using that to manage the threads, but how would I deal with things when the child thread was ready to finish executing? Anyway, I would appreciate any suggestions. Thanks.

Share this post


Link to post
Share on other sites
I am nearly certain that the thread terminates nicely once it finishes, join or not. The docs for the thread object itself implies that the thread does indeed die when the 'main' function (or the program) terminates without a join.

Share this post


Link to post
Share on other sites
Quote:
Original post by Telastyn
I am nearly certain that the thread terminates nicely once it finishes, join or not. The docs for the thread object itself implies that the thread does indeed die when the 'main' function (or the program) terminates without a join.


Yeah, it does imply that, but I'm paranoid. I seem to remember from some Linux programming a while back, that if you didn't call wait() after a child process finished that it remained in a zombie state. I would definitely not want this to happen. I'm just confused as to how it actually takes care of these things.

Share this post


Link to post
Share on other sites
Quote:
Original post by Telastyn
I am nearly certain that the thread terminates nicely once it finishes, join or not. The docs for the thread object itself implies that the thread does indeed die when the 'main' function (or the program) terminates without a join.


Ok, I solved this one myself. Looking in thread.cpp, for the destructor the code is:

thread::~thread()
{
if (m_joinable)
{
#if defined(BOOST_HAS_WINTHREADS)
int res = 0;
res = CloseHandle(reinterpret_cast<HANDLE>(m_thread));
assert(res);
#elif defined(BOOST_HAS_PTHREADS)
pthread_detach(m_thread);
#elif defined(BOOST_HAS_MPTASKS)
assert(m_pJoinQueueID != kInvalidID);
OSStatus lStatus = MPDeleteQueue(m_pJoinQueueID);
assert(lStatus == noErr);
#endif
}
}




So, if you are using Windows, it just releases the thread handle, which means your home free.

If you are using something that implements POSIX threads, like Linux/Unix, then it uses pthread_detach, with means that the child thread gets cleaned up as soon as it is finished.

As for OSX, it looks like it handles that possibility also, so I guess you really are fine just letting the thread object go out of scope and destroy itself.

Share this post


Link to post
Share on other sites

This topic is 3780 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this