Re: Threads docs updated in CVS

From: williamkempf_at_[hidden]
Date: 2001-08-09 11:22:26

--- In boost_at_y..., "Asger Alstrup Nielsen" <alstrup_at_s...> 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.

This is the behavior of even the Win32 WaitFor*() methods when 
applied to a thread.  So it shouldn't be much of a surprise.

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

I'll look at this.
 
> > 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.

Well, this is the behavior of Win32 WaitFor*() methods, so...

I still am hesitant to use a less well known name, however.

Bill Kempf