From: Chuck Allison (cda_at_[hidden])
Date: 2002-01-19 13:03:43
How about "system" threads?
----- Original Message -----
From: "bill_kempf" <williamkempf_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.
> > >when we
> > >> talk about native facilities in the context of a library, we
> > >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
> > the other categories are boost or adopted, and adopted threads seem
> > to be functionally equivalent to a boost threads, except for how
> > came to be, so it seems the features are actually associated with
> > 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
> > >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
> > >be very welcome.
> > The compiler is probably going to align the cancellation disable
> > 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
> > >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
> > >to do it before a call to either of these.
> > Would it be appropriate to describe an instance of boost::thread as
> > 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
> Bill Kempf
> Info: http://www.boost.org Send unsubscribe requests to:
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk