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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-06-28 07:07:49

From: "Gary Powell" <Gary.Powell_at_[hidden]>

> Well for me its the 90/10 rule. (And here it may be even the 99/1 rule)
> where 90% of the time I need a ref counted thread, and yet there is still
> 10% of the time I just cannot have it. Hence in the 2 layer approach,
> "self()" would exist only in the ref counted interface, and I get the
option
> of using what part of this library I need.

I think we need to get into concrete examples. Would you describe a
situation where you absolutely can't have a thread::ref manage the thread
state?

This is related to the join/detach problem. A non-managed, noncopyable
object is only useful when it's "scoped" - like scoped_ptr, but a thread is
rarely scoped.

My limited imagination only comes with the following 'scoped thread'
scenario:

int main()
{
  thread t1(f1);
  thread t2(f2);
  thread t3(f3);
  join_all();
}

... and I think that the performance hit from having a thread::ref in this
case is negligible.

--
Peter Dimov
Multi Media Ltd.