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);
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk