Handling memory exhaustion – State of the art?

help
22

After looking through the Nomicon, I found an example under the section Exception Safety that implicitly answers my question. I feel like it would be good to include memory exhaustion explicitly in the introduction when listing reasons for unwinding:

Although programs should use unwinding sparingly, there's a lot of code that can panic. If you unwrap a None, index out of bounds, or divide by 0, your program will panic. On debug builds, every arithmetic operation can panic if it overflows. Unless you are very careful and tightly control what code runs, pretty much everything can unwind, and you need to be ready for it.

1 Like
23

I'd like to remind everyone that:

  • Windows doesn't have overcommit, embedded platforms don't have overcommit. Dismissing the concept of OOM handling in general, on all platforms, because of overcommit is an incredibly Linux-centric view that hurts Rust's reliability.

  • On all platforms it's easy to artificially limit maximum memory for Rust, which in practice solves the issues with overcommit, swap and other virtual memory weirdness:

Today cap + try_reserve + optionally fallible_collections is still the state of the art.

9 Likes