Boost logo

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