Re: [boost] Re: Review: Boost.Threads

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-09-01 15:37:13

From: <williamkempf_at_[hidden]>
> 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)

Enough off-topic. ;-)

--
Peter Dimov
Multi Media Ltd.