From: Tom Becker (voidampersand_at_[hidden])
Date: 2002-01-19 01:20:08
On Fri, 18 Jan 2002 23:12:50 -0000, "bill_kempf"
> > 1. The terms native and foreign could easily be confusing. Normally
>> talk about native facilities in the context of a library, we mean
>> underlying facilities provided by the platform. Maybe the
>> be boost and native instead, or maybe it would be best to
>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?
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.
>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.
> > 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?
-- Tom Becker "Within C++, there is a much smaller and <voidampersand_at_[hidden]> cleaner language struggling to get out." -- Bjarne Stroustrup
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk