[boost] Re: RFC: Multithreading design constraints

From: jsiek_at_[hidden]
Date: 2000-06-05 12:10:50

There was one thing left implicit in what I was saying... perhaps it
will assuage your fears. By C++ MT API I was thinking in terms of a
*concept* defintion which is completely neutral to the actual types
used to implement the threads, etc. It would certainly be a mistake to
make any mention to the actual pthread_t type or any implementation
details of pthreads_t in this concept definition. I think you'll find
that having such a concept definition naturally encourages
encapsulation.

As for implementing a version of the library in terms separate from
the pthreads API: the C++ function overloading mechanism is wonderful
at handling this sort of this.

That being said... there would be some constraints on the API that
would not normally be there, in some cases the "natural" C++ interface
would not be possible. For example, most pthread objects have an
explicit pair of create/destroy functions. Without moving to wrapper
classes these functions would have to stay... and not be converted to
constructor/destructor. Pretty ugly to say the least.

Cheers,

Jeremy

Miki Jovanovic writes:
 > --- In boost_at_[hidden], jsiek_at_l... wrote:
 > > With regards to pthreads and a C++ MT API... it might be useful to
 > > define the C++ API in such a way that pthread pointers could be used
 > > as C++ thread objects without the need for wrapping them up in a
 > > class.  This is fairly easy to do if the API is defined in terms of
 > > normal functions instead of members. Just create the appropriate
 > > overloads for pthread_t* etc.
 > 
 > Am I the only one that thinks encapsulation rule is a sacred one?
 > Well never mind. People seem to like this. I will agree to this if I 
 > get guarantees that pthreads or any other implementation details are 
 > exposed only as an add-on, and are not required functionality.
 > 
 > Even if we use POSIX or pthreads as a base for our work, it must be 
 > possible to implement the library in terms completely separate from 
 > these API's, hence using pthread_t* will be an error in such a 
 > library.
 > 
 > Cheers,
 > 
 > Miki.
 > 
 > 
 > ------------------------------------------------------------------------
 > IT Professionals: Match your unique skills with the best IT projects at
 > http://click.egroups.com/1/3381/3/_/9351/_/960223323/
 > ------------------------------------------------------------------------
 > 
 > 
 >