Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-06-27 17:27:30


--- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> From: <williamkempf_at_h...>
> > --- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> > > From: <williamkempf_at_h...>
> > ...
> > > How important it is that Gary not pay for (possible) reference
> > > counting he doesn't need I don't know, so I'll leave it to
> > > Gary to actually argue for one of these if he wants. I remain
> > > satisfied with interface 2.
> >
> > These are all syntactic variations on one design (as you know),
and
> > the key to focus on here is the syntax using the shared_ptr.
This
> > gives us creation syntax like this:
> >
> > shared_ptr<thread> p(thread::create(proc));
> >
> > This is nearly identical to the more intuitive syntax:
> >
> > shared_ptr<thread> p(new thread(proc));
>
> But it isn't identical, because the shared_ptr returned by
> create() would have a count of two, not one, which count is
> decremented when the thread function returns.
>
> Well, a small benefit anyway. It's not my favorite design.
>
> > To me the decision comes down to a simple question. Do we need a
self
> > () method? If we do, we must go with "Interface 2" since it's
the
> > only one that will allow for a self() method. If we don't, we
should
> > probably opt for "Interface 1" since it's conceptually a cleaner
C++
> > design and easily allows for ref-counted usage through the above
> > syntax with no modifications to the interface.
>
> No, it doesn't easily allow for ref-counted usage. Or else
> I'm missing something. Perhaps you are assuming that ~thread()
> does a detach(), so the extra count is uneeded? And you are
> assuming that shared_ptr will be made thread-safe soon enough?

Yes.
 
> And that we can get by without self()?

I don't understand what you're asking here. Please elaborate and I'd
gladly answer.
 
> And that the Windows implementation of thread::ref would need
> to use explicit reference counting anyway, rather than the
> (possibly) more efficient DuplicateHandle?

The original implementation required more state than just the
HANDLE. I'm not sure a new implementation with the latest interfaces
would, but regardless you've dropped down into implementation details
and are looking at optimizations... two things we shouldn't do while
discussing the interfaces (unless the implementation details make an
interface prohibitive).

Bill Kempf


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk