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-
> 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
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk