Re: Boost.Threads - thread_desc concept

From: williamkempf_at_[hidden]
Date: 2001-06-27 09:29:44

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "Beman Dawes" <bdawes_at_a...>
> 
> >  >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.

It is very unlikely that we'll have any implementation that's 
portable and uses only the native "thread descriptor" type typedefed 
to thread_desc.  The current implementation, in fact, contains 
several additional pieces of data for both Win32 and pthread 
implementations.  In order to have a "procedural interface" we have 
to either make the thread_desc a structure with all public data or 
make every method a friend.  Both of these are generally considered 
poor design choices for OO systems.  At least the "overglorified 
namespace" approach, where a class is used with static methods 
instead of a namespace, we retain full encapsulation.

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

All the more reason to require encapsulation here!  There's going to 
be some state data that's common across ALL implementations, which I 
gaurantee that some programmer is going to try and manipulate if you 
make it public.
 
> thread::id is, using a file based analogy, a FILE* wrapper with the
> appropriate copy/destroy semantics.

Other than these worries, this is a viable design... but again, is it 
the proper one?

Bill Kempf