Re: Boost.Threads - thread_desc concept

From: williamkempf_at_[hidden]
Date: 2001-06-30 08:56:14

--- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> 
> > There's nothing in thread that's polymorphic.  Designs that
> > make thread a base class add an artifical run() method as the
> > polymorphic operation and this is the actual "threadproc".  
Harnesses
> > have to be used to make this run() entry point do what we really
> > wanted in the first place... run some arbitrary method outside of 
the
> > thread class.
> 
> run() is a bad idea, indeed. however, i am asking
> for support of inheritance primarily for extra
> "thread fields". things such as thread names,
> thread trace files, etc.. IMHO it is better (simply
> more natural) to _extend_ the base thread class
> than to do it via some "my-extra-state" class PLUS
> additional ThreadLocal.

I don't agree that it's more natural.  The native thread types can't 
be extended through inheritance.  Further, most C++ types in the 
standard today can't be extended (safely) through inheritance.  So 
for both those used to native threads and those used to the C++ 
language, there's nothing "unnatural" about extending through other 
means (usually aggregation, but the thread concept gives us other 
options).

> "my-extra-state" would
> probably need to save a ref to the associated
> thread object anyway (in order to avoid self()
> calls for access to base thread object methods)
> so.. why not do it via inheritance?? why should
> i care about new and delete if it could be managed
> via thread object ?? sure I can aggregate thread
> object it into my extra state but how about thread
> local set() and destruction on thread_exit, detached
> threads,... ??  Inheritance nicely solves all these
> "problems" (they are solvable w/o inheritance but
> that is extra work on the user side).

This is the *same* argument people make when they become upset that 
std::basic_string, for example, can't be (safely) extended through 
inheritance.  However, most agree that the standard made the right 
choice in this design decision, and it's the choice Boost.Threads is 
going to make as well.
 
> > *sigh*  Several people have tried to argue this, but the reality 
is
> > that a polling operation such as this can be, and has been, put to
> > effective use.  You're correct, a return value of true doesn't
> > gaurantee the thread is still running by the next instruction so 
you
> > can only rely on return values of false, but that's enough
> > information to be put to effective use in "busy waiting 
operations".
> 
> how about timed_join/try_join -- and it would
> provide a simple mechanism to communicate thread
> function return value along the lines of standard
> pthread_join ? is_alive is really confusing, IMHO

I've considered a timed/try join, and yes this would make the need 
for is_alive() obsolete.  The designs so far in their infancy.  I 
took the minimalist approach, which lead to is_alive() instead of 
try_join().  After we decide on the main design issues I'll re-
evaluate this particular portion.  You should note, however, that 
currently the Boost.Thread library doesn't support a return type.  
Each native thread implementation seems to use a different return 
type, complicating the choice for a return type for us.  Further, 
with the use of function objects we're not limited to a single return 
type (a function object wrapper can store the return in any type 
desired).

Bill Kempf