Re: [boost] Boost.Threads - thread_desc concept

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-06-27 11:22:09

Beman Dawes wrote:

> I'm not disagreeing with any of the above, but I'm worried about the
> negative consequences of providing only that procedural interface.

        I'd provide:

        class thread_api 
                // lighweight API wrapper
                // purpose: platform independence

        class posix_api : public thread_api
                // posix extension

        class win32_api: public thread_api 
                // win32 extension: boost only

        class thread_id
                // copyable thread id wrapper

        class my_favourite_thread_manager
                // design competetion on boost to choose
                // one or more alternatives
 
> * Many programmers will roll their own thread class, wrapping the
> procedural functions, and we will end up with a proliferation of
> incompatible classes, many of which fail under stress because they didn't
> to the wrapping correctly.

        This will happen, but it is _more_ likely to happen if
there is no lightweight thread_api wrapper and people try to
handle platform independence _as well_.

        If in addition we provide one or more thread_manager
classes, some of these users will use that, rather than roll
their own. And some will still roll their own. And some will
still use their platform native C API.

        Consider Felix. It is a code generator. I need a low level
interface. I'm not concerned with mismanagement by the user
at the C++ level. Without the low level interface, I cannot
do threading at all: I do not want to deal with platform
issues.
 
> I see the possibility of those negative consequences as so high that I'm
> willing to put quite a lot of effort in helping Bill, Greg, and other
> boosters find a good, workable thread object interface.

        I agree. So lets separate the three issues:

        1) upgrade the abstract machine to support threads
        2) provide a platform independent lightweight thread_api
           wrapper with semantics specified in terms of the upgraded abstract
           machine model
        3) a thread manager class/classes specified entirely in C++

The key here is the separation of dependencies and purposes:

        1) is required to support (2)

        2) is required for 
                a) platform independent common functionality
                           and to provide a common vehicle for 

                b) platform dependent extension
        3) is required for effective management,
                but only depends on (2) [and not on (1)]
                and so is itself platform independent

Again, we want to allow derived classes to extend the management
scheme, and we may want more than one thread management scheme:
for example a posix scheme might utilise posix features.

I guess what I'm saying is that your concern is real,
and the best way to meet it is indirect: provide the
low level interface precisely to make it easier to build
platform independent higher level ones.

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