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