Re: [boost] Re: Redesigned thread class

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
insist.

> >Consider platforms with more than one threading API, does the
> >implementer have to support them all?
> 
> No.  Adoption is a QoI issue...

Good.

> >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 
> implementations.

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
differ.