Re: Boost.Threads - thread_desc concept

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-07-02 10:42:49

> 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..

regards,
alexander.