Re: Boost.Threads - thread_desc concept

From: williamkempf_at_[hidden]
Date: 2001-07-02 10:48:47

--- In boost_at_y..., "Rainer Deyke" <root_at_r...> wrote:
> ----- Original Message -----
> From: <williamkempf_at_h...>
> To: <boost_at_y...>
> Sent: Monday, July 02, 2001 9:00 AM
> Subject: [boost] Re: Boost.Threads - thread_desc concept
> 
> 
> > void foo()
> > {
> >    thread thrd(&bar);
> > }
> 
> Question: can a thread run without a corresponding thread object?

Yes.  This is a "detached" thread.  The concept exists for both 
native threading libraries targeted today, and I'd suspect it exists 
for all other threading libraries as well.

> If yes:
>   - Non-copyable thread object interface is more efficient.
>   - Less functionality.  For example, running threads can't change 
their own
> priority.

I've addressed the less functionality problem.  The third design uses 
the default contructor to contruct a thread object for the current 
thread.  This causes a few issues with Beman's original argument, but 
it's consistent with iostreams that allow you to create multiple 
instances for the same stream resource.
 
> If no:
>   - The above example won't do anything useful.
>   - Thread object must be allocated on heap anyway in most cases, 
so the
> 'thread::ref' design is likely to be superior with no performance 
penalty in
> most cases.
>   - More functionality.  A static function that returns a reference 
to the
> currently running thread object is possible.
>   - Overall clearer interface.  If a thread object dies, the thread 
dies.

We won't support cancellation (at least any time soon) so this simply 
isn't the case for either design.

> The inverse cannot be true, however: a thread may terminate long 
before it
> is safe to destroy the thread object.

Yes.

Bill Kempf