Boost logo

Boost :

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; }


Makes sense to me. It's like ::ShowCursor() in Win32.

Peter Dimov
Multi Media Ltd.

Boost list run by bdawes at, gregod at, cpdaniel at, john at