RE: Adopted threads and join/wait

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