Re: [boost] Boost.Threads - Alternative Designs

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-08-24 11:15:52

From: <williamkempf_at_[hidden]>
> A couple of people have questioned the latest design for 
> boost::thread and seem to talk about alternative designs.  However, 
> I'm not 100% sure I fully understand their alternatives.  So, since 
> we're under the gun here (only a few days until submission) I'd like 
> to ask that anyone who really would prefer a different design to post 
> a full explanation of the design.  This will help me to evaluate the 
> different options better and to make an informed choice.
> 
> Something else that would be VERY helpful is to point out areas in 
> the current proposal that make it difficult or even impossible to use 
> it as the basis for implementing the alternative design.  As long as 
> there are none then the design I proposed seems to be a safe design 
> to settle on.  If there are problems then I really need to focus on 
> those areas.
> 
> In the end I may not choose any of the alternative designs, or even 
> make changes to the current proposal, but at least I can make an 
> informed choice.  During submission, if you feel strongly against the 
> design I choose you can elect to vote for not accepting the library.

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:

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?

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

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

My bias, as ever, is that it should be possible now, or in a future
revision, to write thread programs in a style that makes errors of
thread memory and lifetime managment easy to avoid.