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

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-08 15:56:34

Alexander Terekhov <terekhov_at_[hidden]> writes:

> David Abrahams wrote:
> [...]
>> > How many times do I need to repeat that the issue here is unneeded
>> > and *hurting* unwinding for ANY unexpected exception -- "normal" C++
>> > "throw-expressions" including.
>> 
>> Maybe until everyone understands why it hurts so badly.
>
> Unexpected means that you can't trust your program state any more. 
> It's all about minimizing the damage

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.  Unwinding doesn't do any damage unless you need
debugging information.

> 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?

>> > I have THE APPLICATION that doesn't handle std::bad_alloc because
>> > it documents its address space size requirements and all
>> > std::bad_alloc's are either "admin errors" or indications of some
>> > serious flaw (leaking, corruption, whatever). I neither *really
>> > want* nor *really can* wrap all "operator new(size_t) and
>> > "operator new[](size_t)" calls with catch(const std::bad_alloc&)
>> > { abort(); } (or replace them with std::nothrow_t stuff and
>> > "if").
>> 
>> No, but you can replace operator new so that it aborts on failure.
>
> This would preclude operations that may attempt to operate in kinda 
> "grab big chunks" mode first (this will work if we're not running at 
> peak memory consumption already) and fall back to "less memory"/"but 
> more CPU" (or die) if that's not the case. 

No, those operations can (and do) use new (nothrow) and/or malloc.

> Now, those beasts do catch std::bad_alloc on one path, and don't
> catch it on the alternative. It is temp/working stuff and no
> allocations (well, except stack extent or two) are done afterwards
> within operation. 

That sentence is only marginally parseable and fails semantic
analysis.

> And, again, I do NOT want to have any "wrapping". Lack of handler
> shall be enough.

AFAICT, what you're talking about are exactly what I saw before: cases
where it would be nice to have 2-phase EH, but where mandating it in
the C++ standard is probably inappropriate.

>> >> The sorts of advantages that apply everywhere are relegated to
>> >> debugging relatively obscure conditions, e.g., that it may be easier
>> >> to debug an exception-specification violation that the runtime can
>> >> detect will be violated at the throw point, since the program can core
>> >> dump
>> >
>> > and, more importantly, failover...
>> 
>> I don't see how failover (switching to backup hardware) can help with
>> what you claim is a programming error.
>
> Failover doesn't help to fix a programming error. Failover means 
> rollback of external transaction, repeating it in a clean address 
> space (we may even move to another system) and simply discarding it 
> if it fails again there. 

Avoiding unwinding is even less important if you're going to throw
out the process state and start over, it seems to me.

>> >>      immediately.
>> >
>> > Right. Some optimizations would be possible too.
>> 
>> Example?
>
> Funny.
>
> http://groups.google.com/groups?selm=3EEDD118.5065FAC9%40web.de
> (Subject: Re: std0X::expected_exception<T>() [repost])
>
> See "...MEMORY ACCESS ORDER" section...". I don't want to "wrap" 
> all those throwing calls used within throw-restricted (may not 
> necessarily be throw()-nothing) scopes and put them inside zillion 
> throw()-nothing forwarders/wrappers. Again, lack of handler shall 
> be enough for compiler to figure it out and apply optimizations.

I wouldn't trade my hostage, which can be grasped in just a few
sentences, for that: it's neither clear nor easy enough.

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