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

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-08 10:33:53

"Peter Dimov" <pdimov_at_[hidden]> writes:

> My understanding of the two phase business is as follows:
>
> Phase 1: search for a handler;
> Phase 2: unwind to that handler and invoke it, but only if a handler was
> found.
>
> Extension: a function that performs phase 1 and returns a bool. No rationale
> (readily) available. Not sure whether, or why, this is a good idea.
>
> This doesn't play well with exception specifications since, if I understand
> them correctly, (and I have no reason to, since I've never used one or seen
> one used,) a violated exception specification is required to unwind, _then_
> call unexpected(), which can then rethrow a different, "conforming",
> exception.
>
> It also implies that catch(...) should never, ever, be used with a rethrow
> as a "finally", since it deceives phase 1. I'm not sure whether this is
> going to work.

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.

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 immediately.  But not all ES violations can be detected that way.

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".  Of course, that sort of guard object is implementable in a
library at the cost of some efficiency, but I expect that those kinds
of resource cleanups are rare.  In any case, we probably ought to
implement the library solution to get some experience with it.

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