From: William Kempf (williamkempf_at_[hidden])
Date: 2001-08-30 10:51:07
From: "Peter Dimov" <pdimov_at_[hidden]>
>From: "William Kempf" <williamkempf_at_[hidden]>
>>The difference is that boost::thread::join is never called for adopted
>>threads.
>
>I don't see anything that prevents the user to do that.
Thread adoption occurs through "current" semantics, which are exposed by
boost::thread through the default constructor. Such thread objects are
non-joinable, as per the documentation for the constructor. Calls to
boost::thread::join() from non-joinable thread objects results in undefined
behavior, and is thus a programatic error.
>No, I don't think that I need to "wait." You are content with undefined
>behavior; so am I.
There is a difference here between the thread and thread_ref designs. It's
undefined behavior to call "join" on *all* threads created through the
default thread constructor, while it's undefined for thread_ref only for
threads "adopted" during a call to current(). This complicates the
usability of the design. It's not a show stopper if users are willing to
except that they can never call "join" on thread_ref objects returned from
current() (since they can't know if the thread was adopted or not), but
since a thread_ref can be joined multiple times this behavior won't be
intuitive and may not be acceptable by the users. I'd really recommend the
compromise. What would be better yet is to have access to the abstract
machine/platform details in order to eliminate the issue of adoption all
together. The standard can do this, we can not.
Bill Kempf
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp