Re: Boost.Threads - thread_desc concept

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