Re: Boost.Threads - thread_desc concept

From: williamkempf_at_[hidden]
Date: 2001-07-02 10:52:06

--- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> 
> 
> > From:  williamkempf_at_h...
> >
> > --- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> > >
> > > > > could you please explain why "thread types can't be extended
> > > > > through inheritance" ?
> > > >
> > > > Because they're not objects.  A Win32 handle can't be 
inherited
> > > > from.  A pthread_t descriptor can't portably be inherited 
from (on
> > > > many platforms it's a pointer).
> > >
> > > uhhfff.. i am not asking for inheritance from Win32
> > > handles or pthread_t ids. they are not thread objects,
> > > indeed. however, they _represent_ objects (internal thread
> > > objects maintained by the implementation), and you could
> > > certainly create _inheritable/extendable_ C++ thread _object_
> > > which would hide pthread_t/handle or whatsoever so that only
> > > that C++ thread object would know that platform 
specific "handle".
> > > everybody else (user program) would simply use C++ ptr/refs
> > > to C++ thread objects; and yes, you could certainly "extend"
> > > these C++ ptrs/refs with ref-counting and either join/destroy
> > > or detach policy. well, please re-check "timed_thread" C/POSIX
> > > example i've posted a few days ago. it is not C++ but it does
> > > implement thread object on top of posix thread id.
> >
> > Too much context has been lost.  The actual context was that 
_native_
> > thread _types_ can't be inherited.  The point being that it's very
> > natural for both users of native types and for C++ programmers to
> > extend functionality through means other than inheritance, which
> > counters your original assertion.  Yes, we could allow inheritance
> > here, but it's simply not a good idea unless there's some virtual
> > method you expect to be overriden in derived classes (see the
> > recently posted coding guidelines), and the only candidate for a
> > thread object would be a run() method, which we both agree is 
harder
> > to use than a function object design.
> 
> there are some virtual methods i expect to be overriden
> in *some* derived classes -- e.g. private start(...)
> (called by launch stub) and private terminate(...)
> (called upon return from thread routine or inside static
> Thread::exit friend), not counting virtual destructor ;).
> as i said before i want inheritance for things such
> as human readable thread names, thread specific trace
> files/logs, thread specific policy with respect to
> dynamic prty adjustment, etc... i think that for
> _these_ things it is more natural and more importantly,
> easier (less work) and more efficient (thread local vs
> thread field) to do it via inheritance from some library
> provided thread base class. it seems that you disagree..
> with an argument that since "base" class does not need
> any _public_ virtual methods inheritance is a bad idea.
> i would agree if there would be no other usage for inheritance
> (such as things i've mentioned) and/or it would not be
> "so difficult" to implement them via aggregation/thread
> locals/etc..

It's simply not difficult to do this with out inheritance.  So, 
you're right, I disagree with you on this concept.  I also believe 
that the C++ committee would disagree as well.  Your arguments are 
identical to the arguments that others have made for making the STL 
containers polymorphic, but the committee did consider this and 
rejected it.

Bill Kempf