Re: Boost.Threads - thread_desc concept

From: williamkempf_at_[hidden]
Date: 2001-06-30 22:36:09

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

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

I don't care if I match posix join semantics.  The desire to not have 
to keep a reference around is a more valid argument, but I'm not sure 
it's compelling.  I'll have to think on it.

Bill Kempf