• ### Popular Now

• 13
• 12
• 9
• 10
• 13

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

## Recommended Posts

##### 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 on other sites
Quote:
 Original post by TelastynI 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 on other sites
Quote:
 Original post by TelastynI 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.