Re: Threads docs updated in CVS

From: williamkempf_at_[hidden]
Date: 2001-08-09 09:38:43

--- In boost_at_y..., "Asger Alstrup Nielsen" <alstrup_at_s...> wrote:
> > on return from "REAL join or native join" the "joined" thread
> > (which *before the join* might have already terminated but not
> > yet been destroyed) does not exist anymore. destroyed.. gone..
> > completely! there is nothing to real/native-join with after that
> > thread has been destroyed. native/real join is a sort of "delete"
> > of internal thread objects. the alternative is to call "detach"..
> > which would first check whether that thread is still running
> > (has not terminated already):
> 
> I see. So, the traditional join has a different purpose from the
> Boost.Thread join: In Boost, the join is not meant as a means of
> clean-up, is it?

No, there still is the issue of cleanup.  When boost::thread::join() 
is called it does not return until the thread of execution is 
finished, it's stack reclaimed and any cleanup handlers called.  The 
only difference is that Boost.Threads, like Win32, treats the thread 
object as a seperate entity from the thread of execution.  Calling 
join() multiple times on this object is valid... any call made after 
the first simply exits immediately since all the cleanup has already 
been handled during the first call.

> As I understand it, the Boost.Thread aims at hiding such book-
keeping
> details from the user.

No, not entirely.  If you don't call boost::thread::join() then the 
thread is in a "detached" state and is not cleaned up in the same 
manner.  This is part of Ross's complaint about including such 
functionality.  Currently Boost.Threads solely relies on the OS to 
reclaim any resources abandoned by the thread when the process 
terminates it.  In the future, once we have proper cancellation, 
detaching a thread in this manner will do a better job of cleaning up 
since the detached threads will be cancelled before main() exits, but 
this is still hardly the same as the "cleanup" done by a call to join
().
 
> So, when we factor this out of the equation, the difference between 
join
> and detach in Boost.Threads is that join waits for exit before
> proceeding. (But then again, I couldn't find detach at all in the
> documentation.)

That's because there's no detach() method.  A thread in Boost.Threads 
is never truly in a detached state until main() exits with out 
calling join() for the thread.  (I know this simplified explanation 
is going to cause consternation for POSIX experts, but let's not get 
bogged down in the POSIX technical meanings for these terms.)

To make things clear, I see no real problem with using the 
name "wait" instead (or any other name).  The name "join" was chosen 
because it's a well known technical term (and not just in POSIX).  
This choice is proving somewhat vexing because the exact technical 
meaning is slightly different from the exact technical meaning in 
POSIX where people are overly familiar with it, and some Windows 
programmers are unfamiliar with the term (despite it being a generic 
term and not a POSIX term).  If there's a big concensus to change it, 
I'm open to doing so, but given that it's the technical term used 
through out the industry I'm hesitant to do so solely based on the 
Win32 and POSIX backgrounds of most of those complaining here.

I must say, though, that the heated debate on this subject is more 
than surprising.  A rose by any other name... (provided that name 
isn't "turtle").

Bill Kempf