Re: Draft of generation 2 thread class

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-18 21:32:27

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> ----- Original Message -----
> From: "bill_kempf" <williamkempf_at_h...>
> 
> > 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.
> 
> Even if we can't envision a realistic usage scenario that places 
them in
> dynamic memory, just consider the consequences if they are, and you 
keep the
> semantics as written. Cancellation might be turned off permanently, 
even
> though all the disablers are destroyed.

I hesitate to say this because I don't want to argue the point too 
much since I mostly agree with the idea in general.  However, 
allocating it on the stack will be no more disastrous (probably less 
so) then sharing it across threads.  In other words I'd envisioned 
the usage to be like that of the scoped_lock classes, meant to be 
used on the stack and never shared between threads.  The user can 
violate this, but if they do it's a simple programming error.  We 
can't prevent them from shooting themselves in the foot.  So the fear 
that allocating them on the heap could cause cancellation to be 
turned off permanently isn't a very strong argument for me.  The fact 
that heap based usage where as long as one exists then cancellation 
is disabled is a stronger argument.  I just wish I could envision a 
usage where this would really be used.

Bill Kempf