Re: [boost] Boost.Threads - Final Design Decisions

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-17 08:28:20

From: "William Kempf" <williamkempf_at_[hidden]>
> I'd prefer to
> leave join() as an explicit operation.  The destructor shall either detach
> the thread if it is still "joinable", or do nothing if it's been joined.

How would you implement this? When a default-constructed thread object is
destroyed it doesn't know whether the thread has been already joined.

This is something that I tried to point out as a problem with the current
design. A thread object is noncopyable but it's possible to create copies of
it using the default constructor; in effect the thread object is a thread
reference minus the "copyability".

A noncopyable thread object _is_ a perfect fit for the thread concept if you
can guarantee that there is one to one correspondence between the actual
threads and the C++ thread objects. Such a design is possible:

thread & create(F f);
thread & current();

[where current() called from within 'f' would return a reference to the same
thread object as create().]

Unfortunately, without garbage collection, the references would become
invalid when 'f' returns (without warning.)

A minor variation can fix this:

shared_ptr<thread> create(F f);
shared_ptr<thread> current();

Now the shared_ptr's would keep the thread object alive after the actual
thread has died. The thread identity would still be preserved.

Of course this is a single typedef away from thread::ref so you all must
hate me by now.

--
Peter Dimov
Multi Media Ltd.