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

From: Asger Alstrup Nielsen (alstrup_at_[hidden])
Date: 2001-08-09 10:32:39

> 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.

Greets,

Asger