Boost logo

Boost :

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.
> > only difference is that Boost.Threads, like Win32, treats the
> > object as a seperate entity from the thread of execution.
> > join() multiple times on this object is valid... any call made
> > the first simply exits immediately since all the cleanup has
> > been handled during the first call.
> I think you should add this surprise to the documentation of join.
> 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
> > 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
> > 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,
> > this is still hardly the same as the "cleanup" done by a call to
> > ().
> I would request that you document this more explicitly, since it's
> 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
> > because it's a well known technical term (and not just in
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at