From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-19 11:56:36
--- 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