From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-06-27 11:14:08
From: Peter Dimov <pdimov_at_[hidden]>
> From: <williamkempf_at_[hidden]>
>
> > 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.
>
> I don't understand why, could you elaborate?
>
> thread::id (or thread::desc, if you like) is an implementation defined
> class; it has no documented public members:
>
> namespace thread
> {
> class id; // implementation defined
>
> id create(function<void>);
> id self(); // or current()
>
> bool is_alive(id /* const & */);
> void join(id /* const & */);
> }
>
> and so on.
>
> If you like, you can alternatively declare some of the free functions as
> public methods:
>
> class thread::id
> {
> public:
> bool is_alive() const;
> void join();
> };
>
> This precludes using an already-existing type for thread::id - not a big
> deal, admittedly.
Right. And I don't know of any existing types that would do
the job anyway.
> The idea is that thread::id identifies a thread. It doesn't represent a
> thread, per se, because its lifetime doesn't match the thread's lifetime in
> the general case.
>
> This is very close to your initial design, except for the name.
And very close to my thread/thread_ref posting. I like it.
> > > 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?
>
> That's not for me to decide. :-)
Perhaps the choice of a thread class versus thread namespace
comes down to whether there are any operations that are best
provided as member functions of thread?