RE: [boost] Re: Threads docs updated in CVS

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-08-10 07:31:38

I've just committed additions to thread.html in CVS to address issues 
raised by Asger and Biil below.  The original wording seemed correct, but 
it was quite terse, so notes have been added.

Comments appreciated.

--Beman

At 11:32 AM 8/9/2001, Asger Alstrup Nielsen wrote:

 >> 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.
 >
 >I think you should add this surprise to the documentation of join. In
 >other words, you should not rely on the reader to know the technical
 >term "join" in the description.
 >I think it's ok to use a technical term, but we have now established
 >that it's not a well-known term to some users, including me.
 >
 >> 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
 >> ().
 >
 >I would request that you document this more explicitly, since it's only
 >mentioned implicitly now.  Also, please consider to add your good
 >reasons to the rationale, since this is a contentious area.
 >
 >> 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).
 >
 >Given that "join" will return immediately on subsequent calls from
 >different threads (and therefore not wait), the name "wait" is not a
 >clear cut winner any longer. However, personally, I still prefer wait or
 >wait_for_exit, along with proper documentation.