Re: first sight

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-17 09:49:14

--- In boost_at_y..., "terekhov" <terekhov_at_d...> wrote:
> --- 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.

Cancellation can be turned off within specified blocks of code, so 
this isn't really an issue.  Again, though, I'm not trying to argue 
for having mutex locks as cancellation points.  I just want a good 
list of pros/cons for rationale on the 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(...).
> 
>   try
>   {
>      // ... plug-in oper ;-) strong
>   }
>   // ... nothrow
>   catch(...)
>   {
>      // ... nothrow
>   }
> 
>   cout << "When do we reach this point?" << endl;

Sorry, you've already convinced me.  I didn't think hard enough about 
your last post.

Bill Kempf