From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-08-27 12:02:52
From: William Kempf <williamkempf_at_[hidden]>
> 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.
By the implementation I meant the compiler and runtime, not Boost.
And I meant the startup code that calls main rather than main
itself. Sorry for the confusion. But I agree that we should not
> >Consider platforms with more than one threading API, does the
> >implementer have to support them all?
> No. Adoption is a QoI issue...
> >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
I was under the impression that you were objecting to "implementation
defined." Anyway, I agree there is nothing wrong with choosing a good
implementation for Boost, at which point it will need to go in the docs.
I think there should also be a caveat that future configurations may
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk