Re: Digest Number 754

From: williamkempf_at_[hidden]
Date: 2001-08-07 08:55:36

--- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> 
> > * Can not call any methods that represent cancellation points
> > (remember, if a function foo calls a function bar that calls a
> > function defined to be a cancellation point, then foo is also a
> > cancellation point) in a method defined with empty throw
> > specifications.  Some argue that this is simply how it should be
> > since obviously the method can throw if it calls a cancellation
> > point.  However, with other exception types you can catch the
> > exception and not propogate it up past the call, while with a
> > cancellation exception you have to rethrow the exception.
> >
> > * Can not call any methods that represent cancellation points 
from a
> > destructor.  It's a very frequent need to do just that, but doing 
so
> > can result in an exception being thrown out of the destructor 
which
> > disallows the object from inclusion in many container types and 
when
> > created on the stack can result in application termination if the
> > stack is being unwound because of another thrown exception.  The
> > complexit in this case is too great to be safely usable.
> 
> that is true unless your function/destructor disables cancellation
> on its entry (and restores the previous state on its exit). that is
> the standard practice to write cancellation-safe code. what is
> needed is simply a cancellation "guard" class, IMHO.

Ahh... my Win32 experience showing through here.  Again, Win32 
doesn't allow cancellation, but unconditional termination.  I'm too 
used to dealing with this form of asynchronous termination, so I 
didn't think this one through appropriately.  The only library I've 
ever used that provides cancellation via exceptions doesn't allow you 
to suspend cancellation in this manner, and I know I despised the 
concept with that library.  Since you've pointed this out my only 
concern with this whole idea is in writing portable code to implement 
it in Boost.Threads.  I simply won't try and tackle this before 
submission, but I'll keep this in mind for later extensions.  You may 
well have shown me the light in how to implement safe and meaningful 
termination in C++, iif we can implement it.

Bill Kempf

Note:  This still will give us some issues with existing code, so I'm 
still a little hesitant.  I'd consider making the language suspend 
cancellation automatically in destructors and possibly in functions 
delcared non-throwing.  This won't necessarily be backward 
compatible, though, so probably won't happen.  Legacy code written 
with out concern for thread cancellation may simply be a problem we 
have to contend with, with the unfortunate consequence that 
cancelling a thread *may* cause an application to terminate 
unexpectedly.