Re: [boost] Re: Boost.Threads - Alternative Designs

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-08-24 13:55:49

Thanks for clearing this up.  The discussion of default contructors,
adopted threads, and join semantics is beyond me right now, and I
haven't time to study it, what with deadlines looming at work (we
have to clear all our outstanding bugs by Sunday night, and we have
to write a new JIT compiler by Nov 15).  So I'll be satisfied if,
however it works out, there is a clear discussion of the issues in
the documentation, with rationale for the final choices.

From: William Kempf <williamkempf_at_[hidden]>
> >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.