Re: [boost] Boost.Threads - thread_desc concept

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-06-27 12:23:10

At 11:31 AM 6/27/2001, Peter Dimov wrote:

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

Mostly on merits, particularly where user response is just speculation at 
this point.  But it can be a mistake to ignore user response entirely.

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

Yes, that's a clear way of putting it.  Specifics would also be needed 
(which could be culled from this discussion thread.) But we need to finish 
the discussion to see if we agree or not.

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

And you are helping.  This stuff is tough, and lots of help is needed.

--Beman