From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-20 15:13:33
--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "bill_kempf" <williamkempf_at_h...>
> > --- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> > > 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.
>
> No, this doesn't actually mean ref-counting (in the usual sense.)
>
> It simply means that currently we have
>
> disable_cancellations(): old_state_(setcancelstate(disabled)) {}
> ~disable_cancellations() { setcancelstate(old_state_); }
>
> whereas Dave's version is:
>
> long tls_cancel_state = 0;
>
> disable_cancellations() { ++tls_cancel_state; }
> ~disable_cancellations() { --tls_cancel_state; }
>
> AFAICS.
>
> Makes sense to me. It's like ::ShowCursor() in Win32.
That's precisely what I meant by ref-counting. If there's a
different term that applies I'd love to know what it is and how the
two concepts differ.
Bill Kempf