Boost logo

Boost :

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
> > you'll want all cancellation points ignored, not just a call to
> > 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
> > of exceptions) are better solved through a RAII concept for
> > 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
> 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

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