From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-01-20 06:46:31
From: "bill_kempf" <williamkempf_at_[hidden]>
> --- 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.
-- Peter Dimov Multi Media Ltd.