[boost] Re: boost::execution_monitor impl under windows

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-08 18:18:24

Alexander Terekhov <terekhov_at_[hidden]> writes:

> David Abrahams wrote:
> [...]
>> I don't see how the mere fact that you've run out of memory means the
>> program state can't be trusted.  If that were the case, out-of-memory
>> recovery would be impossible on every system, under all
>> circumstances.  
>
> It's the same thing as with std::invalid_argument, so to speak.

If so, nobody should be throwing in the first place, so the question
of unwinding doesn't arise... except in poor-quality platforms, where
I agree that a good-quality C++ implementation should implement
2-phase EH to compensate.

>>                Unwinding doesn't do any damage unless you need
>> debugging information.
>
> That's true as long as you have a strong reason to belive that your
> program state is totally okay or that unwinding won't hit some broken 
> invariant.

Yes.  That's a basic assumption you have to make in order to execute
any code.  Once you discover that a program invariant is broken you
should terminate directly.  

I just don't buy the idea that

    the program knows that whenever the library throws exception X it
    has to assume a program invariant is broken

is a realistic and common enough case to mandate language support for
it.

>> > and "speeding up" externally driven recovery.
>> 
>> Have you measured the cost of unwinding w.r.t. this "externally driven
>> recovery" (restarting the transaction in a new process) to show that
>> it's significant?
>
> If you attempt to unwind on a broken program state, you can simply 
> deadlock or loop forever. 

Sure, but unwinding is no worse than any other non-terminate() code
you might execute.  Some library is throwing an exception; from the
library's perspective everything's OK but it can't fulfill a
postcondition (otherwise, it should just terminate).  It seems to me
that if the program knows invariants are broken at that point, they
have probably been broken since the library was first entered.  It's
quite likely that deadlock or whatever would have already happened by
now.  I don't believe in mandating a core language change to handle
gambles like this one.

> External "ping" monitor (e.g. running some "heartbeat" transactions)
> will hopefully detect your effective death but with some
> latency. Termination is also the best/easy way to fence off external
> resources -- you simply can't restart as long as that "crazy zombie"
> is still alive and does something you have no idea what (if/when it
> has access to external resources needed for restart/takeover).

We all agree that termination is appropriate when an invariant is
broken.  What we don't agree on is the ability of outer-level calls to
determine that an invariant is broken based on the type of exception
thrown from an inner-level call.  I believe that goes to the heart of
my objections to ESes.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com