On Thu, Jun 4, 2015 at 7:55 AM, Nick Wellnhofer <[email protected]> wrote:
> I'd simply keep treating OOM errors as fatal.
It's my understanding that this is a deal-breaker for Proton. One of Proton's
use cases is in memory-constrained embedded systems, where it's expected to
handle OOM scenarios gracefully.
Non-fatal OOM handling is only one many Proton requirements and it's not
certain we can meet them all -- but I don't think it's out of the question to
make the Clownfish runtime completely exception free and it's worth
considering.
> Overflow errors are essentially the same as OOM in this context.
Agreed -- we could use OutOfMemoryError exclusively for `new`, `init`, and
`Push`.
> Applications that can deal with OOM errors are extremely rare. For many host
> languages resolving an OOM condition is impossible anyway. For host
> languages with GC, Clownfish could trigger a GC run if a memory allocation
> fails, then retry once.
Yes. And here's where different host bindings might diverge depending on the
nature of the error.
A user of the C bindings would be expected to check for OutOfMemoryError on
Vector's constructor. But most other host languages should handle this
automatically.
That includes Go, where at least some of the time we'd use return codes. It
makes sense to return a FileNotFoundError as a separate value -- but not an
OutOfMemoryError.
// FileNotFoundError conveyed in MAYBEIndexSearcher return value split out
// into separate return value to be handled by user.
searcher, err := lucy.OpenIndexSearcher(path)
// OutOfMemoryError handled implicitly by binding -- constructor has only
// one return value.
vector := clownfish.NewVector(10)
> It's unrealistic to expect that Clownfish applications always check for the
> return value of methods like Vec_Push. Typically, they will just ignore it.
> An unhandled OOM error only leads to hard-to-diagnose problems down the way.
I think that's the case when used from a host language where exceptions are
the norm. But with C, it's debatable.
Marvin Humphrey
