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