Re: [boost] Re: Draft of generation 2 thread class

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.