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

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-10-08 15:14:42

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 and "speeding up" externally
driven recovery.

> 
> > 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. 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. And, again, I do NOT 
want to have any "wrapping". Lack of handler shall be enough.

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

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

regards,
alexander.