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