Re: Draft of generation 2 thread class

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
>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?

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?

Thanks,

   Tom

-- 
Tom Becker                      "Within C++, there is a much smaller and
<voidampersand_at_[hidden]>        cleaner language struggling to get out."
                                                       -- Bjarne Stroustrup