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