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

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-20 14:58:20

williamkempf_at_[hidden] wrote:

> >       Well specified. As to the new join semantics:
> > I have some concern that at one place you argue for the
> > strongest semantics, whereas elsewhere you support
> > thread local storage -- which is a hack -- and consider
> > adopting threads.
> 
> TLS may be a "hack" but it's necessary.  And adopting threads is
> basically necessary as well. 

        "Valid" :-)

> >       Ideally, you could separate 'hacks' like TLS
> > and adoption, from 'top level pure boost threads',
> > with which new well principled designs could be constructed.
> > [Is there a way to do this using, for example, an extra
> > namespace?]
> 
> One of us isn't understanding the other here, so I can't comment on
> this.  Sorry.

        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.

        If this were just a class, I'd say have a base
and a derived class (in a separate header file). 
Another technique would be two namespaces. I don't know
if it is possible, or what the best technique is:
I'm asking if there is a sensible way to _separate_
out the pure interface from the integration extension.

----
	At least one reason is that I'd like to do the
same thing when I bind the threads library into Felix.
Felix really is a 'brand new programming language' :-)
But it also supports 'integration'. In particular,
the primary design impetus comes from telephony
applications where multiple worker threads are
used to distribute events between CPUs: Felix is
specifically designed to 'bind' into such an 
existing architectural framework. most of the
threading interface must be integrated into the binding
code (which maps the existing C++ architecture onto
the Felix driver architecture), since Felix 
cooperatively multi-tasked 'threads' generally
should not only never block, but also never do
expensive operations synchronously. 
-- 
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