Re: [boost] Re: Boost.Threads - thread_desc concept

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-06-30 23:26:58

From: <williamkempf_at_[hidden]>
> --- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> > At 11:41 AM 6/30/2001, Jeremy Siek wrote:
> > 
> >  >On Sat, 30 Jun 2001, Peter Dimov wrote:
> >  >> Creation on the heap is orders of magnitude more expensive than managing
> >  >a reference count.
> >  >>
> >  >> This is the major problem I see with a noncopyable design. [This is not
> >  >> limited to the current discussion, but applies in general.] The design
> >  >> forces the user to use 'new,' a keyword that has no place in user land.
> >  >
> >  >I agree strongly with this. The design should not force the user to call
> >  >'new'. I'd much rather see a copyable thread_id type.
> > 
> > I've also come around to that view.  We may now all be arguing violently 
> > about something we all agree on.
> 
> Well, I don't agree with it ;).  However, it seems like I've become a 
> minority of one, and since my own initial design used ref-counting...

No, your not alone.  Gary and I remain concerned that the thread::ref
implementation might have unacceptable overheads in some cases.  But
I am myself even more concerned about being able to safely manage the
lifetime of the references, and Peter is convinced that clever enough
implementations of thread::ref will be plenty cheap enough.  If Peter
is wrong and Gary is right then I vote for the (slightly redundant)
two layer design.

> I'll stop arguing now.  Give me a few days and I'll have an 
> implementation using thread::ref.

I know it's frustrating, but it's important to get this right.

Perhaps we should just put implementations of the leading two or
three interfaces in the vault and let people get more experience
with the alternatives.

I'll be incommunicado for the next two weeks, so with any luck this
will all be worked out when I return ;->