From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-27 10:30:52
From: "William Kempf" <williamkempf_at_[hidden]>
> No. Adoption is a QoI issue. However, on most (obviously not all)
> platforms even if there's multiple libraries for MT they are all based on
> level constructs so users expect the various wrappers to work together as
> much as possible. Users will expect to be able to write library code that
> works no matter what MT library someone chooses to use in the application
> that links to it. This is not an unreasonable expectation. So a goal of
> Boost.Threads should be (and is) to make it as easy as possible for
> "adoption" to be implementable. The proposed interface does this.
> works flawlessly for both POSIX and Win32 implementations. The thread_ref
> design, however, can't insure this, and in fact adoption on POSIX has been
> shown to be extremely problematic with this design.
Not 100% correct (AFAICS). This is not an inherent property of a
thread_ref-based design. The "implementation defined" current() means that
several different variations are possible:
1. Fully compliant, current() works as intended no matter what (requires
native support.) This is expected to be the behavior of a quality C++
standard library implementation that cooperates with the native threading
library if there is one.
2. (POSIX-based) current() works as intended provided that pthread_join()
and pthread_detach() are never called on an adopted thread.
3. (POSIX-based) current() works as intended except that an adopted thread
is not joinable; whoever created the thread is responsible for joining or
4. (Win32-based) current() works as intented, except that the thread object
associated with the adopted thread is not guaranteed to persist after the
thread_ref is destroyed. (Unless there's some clever way to implement
cleanup handlers on win32 that I'm missing. A __declspec(thread)+destructor
combo doesn't seem to work. A helper DLL might.)
And of course
5. current() cannot be used to adopts threads.
I should also add that when, in the future, thread cancelation is added to
the library, canceling an adopted thread would likely lead to undefined
behavior -- this applies to both designs. (Unless - again - I'm overlooking
a clever solution to the problem.)
> The complaint is that
> the proposed design makes a thread_ref design difficult to be implemented
> top of it, but my contention is that the issues are nearly identical to
> implementing a thread_ref design on top of POSIX to begin with.
Depends on which variation you have in mind. #2 is possible with pthreads
but not the current Boost.Threads, #3 is possible with both -- except for
the main thread problem with Boost.Threads.
> The one
> difference is a theoretical allowance for the "initial thread", but I find
> it very difficult to distinguish this thread from any other in this
Just to clarify, are you saying that Boost.Threads will never allow users to
join the 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