Re: Boost.Threads - thread_desc concept

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-06-29 13:07:51

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

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

regards,
alexander.