Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-16 18:20:48


--- In boost_at_y..., "terekhov" <terekhov_at_d...> wrote:
> --- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> > --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > > From: "bill_kempf" <williamkempf_at_h...>
> > > > --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > > > > A programmer that wants to catch the cancellation exception
> may
> > > > have good
> > > > > reasons to do so. In particular, letting an exception
escape
> > from a
> > > > > destructor during stack unwinding terminates the process,
no
> > > > questions
> > > > > asked. ;-)
> > > >
> > > > That's not a reason to catch the request, it's a reason to
> > DISABLE
> > > > requests. A cancellation "exception" can be uncatchable and
> > still be
> > > > safe in cases such as this.
> > >
> > > So, code that currently has
> > >
> > > try
> > > {
> > > // ...
> > > }
> > > catch(...)
> > > {
> > > // eat exceptions, we're in a destructor
> > > }
> > >
> > > will need to be fixed to disable cancellation as well.
> >
> > Only if it makes calls to any "cancellation points".
>
> Such as thread-shared data access, mutex locking?

I'm still trying to determine what should be a cancellation point and
what shouldn't. That's why I'd really appreciate your writing up the
pros/cons of having the mutex lock be a cancellation point. I'm
fairly certain it shouldn't be, but at the very least I'll have to
document the rationale behind that decision.

> Also, with respect to auto_rethrow_exception:
>
> scoped_lock lock( systemWideMutex );
>
> beginUpdates(); // modify something; nothrow
>
> try
> {
> // ... plug-in oper ;-) strong
> }
> // ...
> catch(...)
> {
> // ...
> }
>
> finalizeUpdates(); // final modifications; nothrow
>
> return;

Such code isn't exception safe any way. I don't find that to be a
compelling argument.

In other words, "finalizeUpdate" needs to be either in a RAII
mechanism or placed in the catch(...).

Bill Kempf


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk