Boost logo

Boost :

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
> > can result in an exception being thrown out of the destructor
> > disallows the object from inclusion in many container types and
> > 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at