Re: Draft of generation 2 thread class

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-18 18:12:50

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> Hi Bill,
> 
> I like your format; I may adopt it for Boost.Python.
> I have just two criticisms:
> 
> 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.

> 2. disable_cancellations would be much more useful if it specified 
that
> threads are disabled as long as one of these objects exists, as 
opposed to
> restoring the state to the previous setting upon destruction. I can 
imagine
> that there may be uses for disable_cancellation objects in dynamic 
memory.
> Would it affect efficiency much to make this change?

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.

> 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.
 
Bill Kempf