Re: Boost.Threads - Final Design Decisions

From: williamkempf_at_[hidden]
Date: 2001-08-22 08:07:48

--- In boost_at_y..., John Max Skaller <skaller_at_m...> wrote:
> williamkempf_at_h... wrote:
> > 
> > --- In boost_at_y..., John Max Skaller <skaller_at_m...> wrote:
> > > williamkempf_at_h... wrote:
> > >       Try again. If this were a new programming language,
> > > and you were designing a brand new library for it, you would not
> > > need TLS or thread adoption. So it would be nice to have two
> > > interfaces: one for brand new threading applications,
> > > the 'pure' boost interface, and an extension which also
> > > supports integration with exitsing code.
> > 
> > TLS can simply be ignored in this case.  As for "adoption"... if 
your
> > language interfaces with libraries from other languages then 
you're
> > going to need to "adopt" native threads created by other people.
> 
> 	I'm going to try again. I have no dispute with your
> assertions. I have no dispute with the need for TLS and adoption.
> However, the need does not exist when creating a brand new
> boost supported program using the threads library. You can do
> everything without TLS and without adoption in many such cases.
> So I'm asking if there is a way to factor the threads library
> so I can be surer in such cases that I'm not using the TLS
> or adoption features, for example by using inheritance,
> or namespaces, or even header files, so that I can just
> include the 'pure' part of the library that is self
> consistent and doesn't interface with legacy code, the
> native OS, or other threads.

Again, I don't think it's possible for you to do without adoption, 
period.  If you interface with *ANY* library code there's a 
possibility that your own code will inadvertantly call thread() in a 
thread not created by Boost.Threads.  Further, adoption is a hidden 
implementation detail, so what purpose would there be to disallow it 
even if you can somehow prove you don't need it?

And, again, as far as TLS is concerned, you simply don't use it.  I 
see no need to somehow shield you from "accidently" using it.

> 	At worst, can you separate, clearly, the 'pure'
> boost threads library from the compatibility extensions
> in the documentation, even if a language based separation
> isn't convenient?
> 
> 	It is possible, I think, to separate discussion
> of the 'pure' semantics from the more difficult pragmatics
> of legacy code and implementation support. It may even
> be worth splitting any proposal to the committee. 
> One reason is: it is likely the abstract machine MUST be
> extended to support the 'pure' semantics and interface,
> on the other hand it may be _impossible_ and pointless
> to support thread adoption in the abstract machine.
> Therefore the thread adoption semantics, when Standardised,
> are likely to be 'optional and implementation defined',
> whereas we'd like the 'pure' threading library semantics
> to be deterministic, normative, and well specified
> in terms of the abstract machine model.

Adoption *IS* an implementation detail.  You won't find a single 
reference to it in the documentation or in the libraries interface.  
But it's a very high profile QoL issue that every implementation must 
address.
 
> 	I hope this is clearer. I'm merely asking
> if the library (or at least the documentation)
> can be factored in some way, and it's only a request
> for information -- not any kind of demand for action. :-)

Well, adoption is simply irrelevant.  If you feel very strongly about 
TLS then propose some method to "factor" it.  Simply putting it in a 
different namespace isn't going to prevent you from using it (or even 
discourage you from using it), and even if your own code doesn't use 
it other code you link to might, so I see little benefit in this sort 
of factoring.

Bill Kempf