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

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-10-08 12:34:00

David Abrahams wrote:
[...]
> I asked David Butenhof to explain the issue since I couldn't get any
> other explanation.  We had a long discussion about it.  Basically, the
> conclusion I (we) came to was that 2-phase EH is a good QOI choice as
> a workaround for platforms where exception throwing due to
> "asynchronous" interrups like crashes and signals has been instituted,
> but that mandating it in the standard would be a mistake, because it
> provides very few advantages on other platforms, and there is no
> advantage to that kind of crash=exception throwing in the first place.

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

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

>      immediately.  

Right. Some optimizations would be possible too.

> But not all ES violations can be detected that way.

Really? Such as? Please elaborate.

> 
> One thing we decided might be useful is a way to label _certain_
> cleanups, such as those that delete files used as inter-process
> mutexes, as "should happen on termination, even if no unwinding
> occurs".  ....

http://lists.boost.org/MailArchives/boost/msg53112.php
(If you insist on emergency cleanup...)

regards,
alexander.