Re: Boost.Threads - Alternative Designs

From: William Kempf (williamkempf_at_[hidden])
Date: 2001-08-24 13:22:44

>I prefer the thread::ref design, but I wouldn't reject your (excellent)
>work on that basis.  It is clear that your design is a good one for a
>broad range of uses, and I want to accept it.
>
>I've lost track of the discussion recently, and my copy of the docs is
>dated Aug 1, so let me just ask some questions to catch up:

The latest proposal was never checked into CVS since it added a lot of 
restrictions on usage that I thought may be controversial.  However, they 
vastly simplify the implementation, are much closer to POSIX specifications, 
etc.  So I may go ahead and check it in any way so that people can look 
directly at the docs/implementation.  There's definately controversy on the 
design, hence this particular query, but given the time constraints and the 
issues with other designs...

>1) Is there a function that returns a pointer or reference to the
>   boost::thread object for the thread that it is called on?  If not,
>   why not?  If so, what does it do if the thread object is gone?

No, but there's a default constructor that achieves the same purpose.  Like 
other C++ resource wrapping designs such objects can outlive the lifetime of 
the wrapped resource, but the set of valid operations become very 
constrained at that point (basically to the point where the only valid 
operation is destruction in our case).

>2) Do we know that shared_ptr<thread>(new thread(func)) will suffice
>   for memory management?  If not, why not?

Accept for "join" semantics with regards to adopted threads, yes we're sure.

>3) If shared_ptr is unworkable or inefficient, are there any obstacles
>   to introducing thread::ref in the future?

The issue is squarely with "join" semantics for adopted threads.

Bill Kempf

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp