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
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk