Boost logo

Boost :

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

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, gregod at, cpdaniel at, john at