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

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-06-27 16:53:21

From: <williamkempf_at_[hidden]>
> --- 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?

And that we can get by without self()?

And that the Windows implementation of thread::ref would need
to use explicit reference counting anyway, rather than the
(possibly) more efficient DuplicateHandle?