Subject: Re: [boost] [Boost-users] [review][constrained_value] Review of Constrained Value Library begins today
From: Mika Heiskanen (mika.heiskanen_at_[hidden])
Date: 2008-12-23 23:31:22
Thomas Klimpel wrote:
> So a manageable solution would be to handle "valid" user errors
> before entering the parallel sections of the programm, handle
> the few remaining "valid" exceptions (like out of memory
> conditions) by explicit communication between the workers,
> and don't try to recover from "logic errors" inside
> the parallel sections. This may force me to structure
> my (parallel) algorithms such that they have explicit
> resource allocation phases (during which no
> communication occurs, but exceptions are allowed), and
> running phases (during which no exceptions are allowed,
> but communication may occur). Does this solution makes
> sense? Is there a better solution for this problem?
I usually try to follow the structure you described.
However, previously I had seen no serious harm in throwing
inside the running section even if I knew I had done
the same test in the first phase.
David Abrahams wrote:
> Detecting either a broken supposed-invariant or a failed
> precondition means there's a logic error in the program
> and state may already be arbitrarily corrupt.
Thank you, this pretty much nails it for me. I do believe
is more lenient in the definition. In particular this sentence
If a precondition is violated, the effect of the section of
code becomes undefined and thus may or may not carry out its
seems to allow more for a chance of recovery. David's
"state may already be arbitrarily corrupt" would make a big
difference in conveying the seriousness of the situation.
--> Mika Heiskanen
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk