|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-06-27 10:59:48
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.
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.
> > 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. :-)
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk