Boost logo

Boost :

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

> "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
> > 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
> > can only rely on return values of false, but that's enough
> > information to be put to effective use in "busy waiting
> 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

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at