Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk