Re: [boost] Boost.Threads - thread_desc concept

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-06-27 09:20:26

At 09:27 AM 6/27/2001, Peter Dimov wrote:
 >From: "Beman Dawes" <bdawes_at_[hidden]>
 >
 >>  >Why not use something like
 >>  >
 >>  >namespace thread
 >>  >{
 >>  >    class id; // or 'desc', if you like
 >>  >
 >>  >    id create(...);
 >>  >
 >>  >// etc
 >>  >};
 >>
 >> Yes, that sort of low-level interface is the fallback if we can't work
 >out
 >> a "spirit of C++" interface.
 >>
 >> While I'm really pressing to see if it is possilbe to develop a high
 >level
 >> interface, I'm not opposed to making the lower level interface public,
 >just
 >> as the C++ standard supports both <cstdio> and <iostream>.
 >
 >But this low-level, non-C++-spirited interface is nearly equivalent to 
the
 >class-based one that Bill posted; that was my point. The user never deals
 >with 'thread' instances anyway; the thread class is a "glorified
 >namespace",
 >as Bill correctly noted. The user creates, and manipulates, only
 >thread_desc
 >instances - this corresponds to thread::id above.
 >
 >FWIW, I actually like procedural interfaces, when they fit. There is
 >nothing
 >inherently low-level about them. thread::id may implement the
 >handle/refcounted body idiom under the hood, or it may be a Win32 HANDLE. 

 >In
 >a way, this interface is higher level, because it hides more of the
 >implementation.
 >
 >The important difference between thread::id and FILE* is that a FILE* may
 >leak. A thread::id can never leak. It has proper value semantics, so the
 >'thread reference' it contains will be released upon its destruction; and
 >the thread will terminate itself when it's done.
 >
 >thread::id is, using a file based analogy, a FILE* wrapper with the
 >appropriate copy/destroy semantics.

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.

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

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

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.

--Beman