Boost logo

Boost :

From: William Kempf (williamkempf_at_[hidden])
Date: 2001-08-27 08:50:20

From: "Greg Colvin" <gcolvin_at_[hidden]>
>From: <williamkempf_at_[hidden]>
>>No, it's not under the control of the implementation. In neither
>>Win32 nor POSIX does the implementation create the "initial thread".
>>Even differentiating the "initial thread" from other threads is not
>>really possible, short of using an "Init" class that's required to be
>>instantiated in main(), or using a "thread_main()" alternate entry
>>point, both of which are crude hacks that I'd rather avoid.
>The main() routine is under the control of the implementation
>in the sense that the implementer writes it, can so do whatever
>is needed to be sure the initial thread can be adopted, if we
>insist that it must.

This is not always true, and all solutions that I can devise to do this
would result in a restriction on when threads can be created, which is
another issue. I don't like such "hacks" and wish to avoid them.

>Consider platforms with more than one threading API, does the
>implementer have to support them all?

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 OS
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. Adoption
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. The complaint is that
the proposed design makes a thread_ref design difficult to be implemented on
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. 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 regard.

>So I am quite happy with "implementation defined".

Which is the case. Adoption is never mentioned in the documentation, nor
gauranteed to work. However, I've chosen a design that makes it as easy as
possible to "adopt" threads no matter the platform/implementation, and
allows us to have full adoption capabilities with the two target

Bill Kempf

Get your FREE download of MSN Explorer at

Boost list run by bdawes at, gregod at, cpdaniel at, john at