Re: [boost] Re: Boost.Threads - Final Design Decisions

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-21 16:45:12

williamkempf_at_[hidden] 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.

        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.

        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. :-)

-- 
John (Max) Skaller, mailto:skaller_at_[hidden] 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net