Date: 2001-07-01 08:02:08
--- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> From: <williamkempf_at_h...>
> > --- 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
> > > >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.]
> > > >> 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
> > > about something we all agree on.
> > Well, I don't agree with it ;). However, it seems like I've
> > minority of one, and since my own initial design used ref-
> No, your not alone. Gary and I remain concerned that the
> implementation might have unacceptable overheads in some cases. But
> I am myself even more concerned about being able to safely manage
> lifetime of the references, and Peter is convinced that clever
> implementations of thread::ref will be plenty cheap enough. If
> is wrong and Gary is right then I vote for the (slightly redundant)
> two layer design.
I still see no way to make the management insignificant, especially
if you consider the addition of a v-table significant, since this
management is almost certainly going to be more expensive since it
must be thread safe.
> > 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.
I know it's important to get this right. Unfortunately, there's no
way to prove one design right over another with out extensive
experience, which we can't really gain. Since most people are
convinced that the thread ref approach is the better way to go with
out the experience, I'm willing to go that route.
> 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.
Not a bad suggestion... however, I'm not sure how much experience
people will gain. I'm not sure it'll be enough to really determine
anything. What would be better is to do some timings on the thread
ref approach... but with out an optimal scheme for managing the
references the timings are pointless. And I simply don't see how
Peter's going to optimize this.
> I'll be incommunicado for the next two weeks, so with any luck this
> will all be worked out when I return ;->
Well, I expect there'll be a Boost.Threads submission within that
time frame, so it depends on what you mean by "worked out". Someone
could complain during the submission process that we chose the wrong
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk