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.
// lighweight API wrapper
// purpose: platform independence
class posix_api : public thread_api
// posix extension
class win32_api: public thread_api
// win32 extension: boost only
// copyable thread id wrapper
// 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
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk