From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-28 09:58:46
From: "William Kempf" <williamkempf_at_[hidden]>
> From: "Peter Dimov" <pdimov_at_[hidden]>
> >2. (POSIX-based) current() works as intended provided that pthread_join()
> >and pthread_detach() are never called on an adopted thread.
> This is more than a tad confusing. A "POSIX-based" current() *IS* a
> compliant" current, no matter what definition of "compliant" you want to
> choose. The minor restriction added here that "pthread_join() and
> pthread_detach() are never called on an adopted thread" is, in practice,
> what most code does already. This is the proposed semantic since it
> provides "fully compliant" adoption on both target platforms and is likely
> to allow "fully compliant" adoption on any other platform as well. It's
> only one of the options you list that can do this.
(POSIX-based) refers to the fact that the implementation is POSIX-based.
Fully compliant current() means that it produces a reference to a
full-featured thread object, as if the thread has been created by the
Your proposed semantics is #3 and not #2 since #2 implies that the thread
object that has been implicitly created when current() adopts a thread will
be either joined via pthread_join (by using thread::join) or detached via
pthread_detach in the destructor. This is why it's required that user code
does not call either pthread_join or pthread_detach on an adopted thread.
> >3. (POSIX-based) current() works as intended except that an adopted
> >is not joinable; whoever created the thread is responsible for joining or
> >detaching it.
> This is identical to (2).
It is not. It is identical to your current semantics. An adopted thread is
not joinable, and the destructor does not detach.
> I beg to differ. #2 is the very definition of the proposed Boost.Threads
> implementation (and again I see no difference between #2 and #3). So long
> as the thread_ref design uses "wait" semantics instead of "join" semantics
> the implementation is identical whether done on top of Boost.Threads or
> POSIX threads (provided I lift the restriction on the "current" thread
> object being valid only within the current thread of execution, which I
> I could do if this were a show stopper).
I don't quite understand. Why should a thread_ref use "wait" semantics? As I
said, thread_ref join is exactly equivalent to boost::thread::join.
> I don't know, frankly. In general I consider it to be a design flaw to
> the initial thread, so see no purpose in treating it any differently than
> any other adopted thread.
The difference is obvious. A fully compliant C++0x program (assuming that
C++0x has threads in the standard library) that doesn't use any pthread_* or
other native threading calls does not have any need to adopt threads, but it
does have a main thread.
-- 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