Re: Draft of generation 2 thread class

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