Re: Boost.Threads - thread_desc concept

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-06-30 11:53:14

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

could you please explain why "thread types can't be extended
through inheritance" ?

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

how about join/timed_join/try_join returning function object
which in turn would be able to "return" function result if
needed ?? the point is that until join completed the function
object is basically useless with respect to return value(s) and
i do not want to keep ref/ptr myself until join. It would also
match posix join semantics.

regards,
alexander.