Boost logo

Boost :

From: Tom Becker (voidampersand_at_[hidden])
Date: 2002-01-19 01:20:08

On Fri, 18 Jan 2002 23:12:50 -0000, "bill_kempf"
<williamkempf_at_[hidden]> 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
>> 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?

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, gregod at, cpdaniel at, john at