Re: Review: Boost.Threads

From: williamkempf_at_[hidden]
Date: 2001-09-01 17:40:16

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
> > Actually, changing the state is *more* elegant.  During a 
destructor
> > you'll want all cancellation points ignored, not just a call to 
lock
> > a mutex.  If a non-cancelling variant is needed for every
> > cancellation point then the library becomes more difficult to
> > understand as you have numerous seemingly identical methods.  The
> > problems you refer to (restoring the previous state even in the 
face
> > of exceptions) are better solved through a RAII concept for 
disabling
> > cancellation.
> 
> No, I wasn't referring to exceptions; we're in a destructor in the 
middle of
> stack unwinding so exception safety is our least concern. ;-) 
(Although - of
> course - the save/restore operation would be RAII.)
> 
> The problem is when two save/restore 'windows' from different 
threads
> overlap:
> 
> thread A: get A state
> thread A: set A state to disabled
> thread B: get A state (just've been disabled)
> thread A: restore A state
> thread B: restore A state (to disabled, not what we want)

Ahh... but with a scoped RAII concept for this, the above shouldn't 
happen. ;)

> Enough off-topic. ;-)

Yeah, we'll discuss it at length when cancellation is added.

Bill Kempf