Re: [boost] Critique of Boost.Threads

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2005-05-04 13:59:29

Kevlin Henney wrote:

> Although Boost.Threads uses templates in expressing
> some of its capabilities, it is a relatively closed design wrt
> extension, and hence not what would normally be termed generic.

A partial list of features I expect in the documented interface of an
open thread library:

1) Ability to define my own thread implementation that is compatible and
cohesive with the included implementation

2) Ability to use more than one implementation at once in different
parts of the code. (For example, on Cygwin, you could conceivably use
POSIX threads and Win32 threads in the same application.)

3) Ability to extend the existing implementations to take advantage of
underlying features of the threading implementation that may require
private thread handles

4) Cohesiveness with arbitrary demultiplexors.  (For example, there
should be some adaptor that lets me wait for threads in an application
based on the popular libevent library.)

5) Ability to dynamically load any of the above parts after execution
has started, so arbitrary implementations might be provided (possibly
for some additional penalty).

Related to #3 above, I am wondering what the standard committee's
current feeling is on providing some way for user code to access inner
handles of standard library abstractions.  Of filebuf, this is a fairly
common request.

I've been thinking about Dave Abraham's suggestion
<http://lists.boost.org/boost/2005/03/21839.php> that theres no reason
to provide a special protection mechanism for these inner handles.  The
feeling I get from many here is that you should be able to hit a red
button, such as including a special implementation header, and you're
back in shoot-yourself-in-the-foot land, with the confidence that "the
programmer knows what he's doing."

I've decided that this is not compelling for me.  We always know what
we're doing--we're superheroes, we're C++ programmers.  Yet C++ is
partly about letting us define a set of rules for ourselves, to catch
our mistakes, and keep us honest.  I think the ability to hit this red
button and suddenly have full license to blow away a class's invariants
without any of the traditional protection mechanisms is downright barbaric.

I think there *is* something special about inheritance.  The "protected"
keyword gets wonderful milage in other application domains, and I have
no idea why system abstractions need to be any different, such that for
system dependence, its perfectly acceptable to revert to
pre-Dijkstraesque programming practices.  Certainly noone would tolerate
this additude with other well-defined standard libraries: no matter how
much you beg, you just aren't going to get anyone to give you a pointer
to std::list's linked list head.

People point out that shared_ptr can be persuaded to give up it's
pointer, to let the programmer do what he needs if required.  However,
this isn't the same; the pointer isn't actually part of the
implementation.  For example, you'll never be able to directly
manipulate its reference count, even if you pull rank and flash your
system-specific badge.

Maybe inheritance isn't the right mechanism.  But I think there should
be something that isn't as heavy-handed as just giving up and stripping
down.  I think that once an acceptable mechanism is invented, it could
be applied across the board to not just thread, but std::filebuf,
boost::filesystem, sockets, and other similar components.

Sorry for the length,

Aaron W. LaFramboise