Re: [boost] Re: Draft of generation 2 thread class

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2002-01-19 13:46:45

From: "Chuck Allison" <cda_at_[hidden]>
> How about "system" threads?

As opposed to "user" threads?

> ----- Original Message -----
> From: "bill_kempf" <williamkempf_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Saturday, January 19, 2002 9:56 AM
> Subject: [boost] Re: Draft of generation 2 thread class
> 
> 
> > --- In boost_at_y..., Tom Becker <voidampersand_at_f...> wrote:
> > > On Fri, 18 Jan 2002 23:12:50 -0000, "bill_kempf"
> > > <williamkempf_at_h...> wrote:
> > > >  > 1. The terms native and foreign could easily be confusing.
> > Normally
> > > >when we
> > > >>  talk about native facilities in the context of a library, we
> > mean
> > > >the
> > > >>  underlying facilities provided by the platform. Maybe the
> > > >categories shoudl
> > > >>  be boost and native instead, or maybe it would be best to
> > > >avoid "native"
> > > >>  altogether?
> > > >
> > > >I agree, and expected these names to raise controversy.  I just
> > > >couldn't come up with alternatives. "boost" instead of the
> > > >current "native" is a good choice.  I'm not so sure about
> > > >using "native" instead of "foreign", though it's better.  I'm very
> > > >open to suggestions here.
> > >
> > > How about "platform" threads?
> >
> > Not bad.  Better then native, but I hope we can still do better :).
> >
> > > I was initially confused by the places where the document said some
> > > feature is available only on category != foreign. I figured out
> > that
> > > the other categories are boost or adopted, and adopted threads seem
> > > to be functionally equivalent to a boost threads, except for how
> > they
> > > came to be, so it seems the features are actually associated with
> > the
> > > thread's boostness, which makes sense.
> >
> > Correct.  When you put it this way, I suppose we could eliminate
> > the "adopted" state and just let the adopt() method promote the
> > thread to a "boost" state.  There may be a need to determine if a
> > thread has been adopted, though, so I'll hold out for the three
> > states at least for now.
> >
> > > >Hmmm... interesting thought.  Means ref-counting, but as long as
> > > >these instances aren't shared between threads (and they shouldn't
> > be)
> > > >this isn't going to effect the speed much at all.  I can't envision
> > > >the scenario in which this would actually be useful, but I'm not
> > > >adverse to considering it.  Some further discussion about this
> > would
> > > >be very welcome.
> > >
> > > The compiler is probably going to align the cancellation disable
> > flag
> > > anyway, so those bits are just waiting to be used for something.
> >
> > I realize this, I'm just wondering if the scenario Dave described is
> > useful enough to account for it in the specification.  In other
> > words, I'm wondering if it might be a bad idea (as in prone to some
> > user error) to use this scheme, as well as whether there's a
> > legitimate need for it despite any possible dangers.
> >
> > > >  > And a question:
> > > >  >
> > > >  > Would it make sense to have the thread destructor post a
> > > >cancellation to the
> > > >  > thread it manages?
> > > >
> > > >Not since there can be multiple thread objects representing a
> > single
> > > >thread of execution.  You don't know which of these objects is
> > > >actually "managing" the thread.  (Think of thread objects as a
> > > >specialized form of a pointer in this regard.)  Also, the managing
> > > >thread object must call either join() or detach() or resources will
> > > >be leaked, and in general if you want to cancel a thread you'll
> > want
> > > >to do it before a call to either of these.
> > >
> > > Would it be appropriate to describe an instance of boost::thread as
> > a
> > > thread reference object?
> >
> > Yes, except that others expect to employ a thread_ref design on top,
> > which means something totally different but could still confuse some
> > users.
> >
> > Bill Kempf
> >
> >
> > Info: http://www.boost.org  Send unsubscribe requests to:
> <mailto:boost-unsubscribe_at_[hidden]>
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
> >
> 
> 
> 
> Info: http://www.boost.org  Send unsubscribe requests to: <mailto:boost-unsubscribe_at_[hidden]> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 
>