Re: [boost] Boost.Threads - thread_desc concept

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-06-27 10:31:06

From: "Beman Dawes" <bdawes_at_[hidden]>

Interesting points...

> I'm not disagreeing with any of the above, but I'm worried about the
> negative consequences of providing only that procedural interface.
>
> * 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.

I'll have to accept your judgement for this. I don't see why a programmer
should wrap the interface in a class unless there is something that is
gained - except the f(x) vs x.f() syntax; but it's possible that many will
do so.

This is a very interesting question; should we judge a design not on its own
merits, but on what we feel would be the user response to it.

I think that we should keep in mind that the "average C++ user" may well
shift his/her mindset away from "OO for its own sake" by the time the thread
library gets standardized and widely accepted.

> * Endless hours will be wasted explaining over-and-over again why there
> isn't a "real C++" thread class in the library.  Part of the reason (the
> other was the name) this discussion started was the lack a convincing
> sounding rationale for the lack of a real threads class.

The rationale is that the (current) 'thread' concept is not well represented
by a class.

I'm not saying that having a Thread class is a bad thing; only that layering
an "OO" wrapper on top of a procedural interface doesn't make the interface
less procedural, or higher level.

> * Some programmers won't bother to wrap, and won't bother to ask for
> rationale.  They will just reject the library out-of-hand because of the
> lack of a "spirt of C++" thread class.  That may well include the
standards
> committee.

Another strong point; although the STL has already redefined the "spirit of
C++", so the committee may be more receptive to "novel" design approaches.
:-)

> 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'm just trying to help.

--
Peter Dimov
Multi Media Ltd.