Re: first sight

From: terekhov (terekhov_at_[hidden])
Date: 2002-01-16 18:50:59

--- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> --- 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.

Just ask Peter whether he wants that his shared_ptr's 
++ and -- would start throwing exceptions by default 
in thread-safe version of his class.

> 
> > 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(...).

  try
  {
     // ... plug-in oper ;-) strong
  }
  // ... nothrow
  catch(...)
  {
     // ... nothrow
  }

  cout << "When do we reach this point?" << endl;

regards,
alexander.