> Has driven changes in upstream Rust: more try_ methods for Vec that don't panic in OOM: https://github.com/rust-lang/rust/pull/95051
I was curious to have a look at that PR, but it seems it was closed after a long discussion (mainly because it would add ~30% more methods to Vec?). So which changes landing in upstream Rust is the bullet point referring to? Was the Keyword Generics Initiative born out of this?
Sort of. Rather than bolting on fallible methods adhoc to an existing type, it was felt it would be better to take a step back and actually design this properly. This includes third party crates experimenting with different options.
Maybe we should have a FallibleVec type? Maybe common vec-like methods could be abstracted out in to a `RawVec` type? Maybe both? Maybe the (unstable) `Allocator` API could be adapted to better suite all these cases? Whatever the case it's not great to be adding on a ton of methods in the heat of the moment.
It doesn't always mean that your app has no memory, it just means that your chosen allocator has no free memory. That's not always an unrecoverable situation.
1. It's not always possible to detect memory allocation failure (e.g., Linux overcommit). So many applications will have to design their operation around the possibility that out-of-memory means someone is going to axe their process unwillingly anyways to support those platforms.
2. Memory allocations tend to be pretty close to omnipresent. If you consider a stack overflow to be a memory allocation failure, then literally every call is a chance for memory allocation failure. But even before then, there's often the use of small amounts of heap memory (things like String in particular).
3. Recovery from OOM is challenging, as you can't do anything that might allocate memory in the recovery path. Want to use Box<dyn Error> for your application's error type? Oops, can't do that, since the allocation of the error for OOM might itself cause an allocation failure!
https://rust-for-linux.github.io/docs/alloc/vec/struct.Vec.h...
NB The prose for Vec here, including examples, is copied from the "real" Vec in Rust's standard library, so it talks about features like push but those are not actually provided in Rust for Linux.
If you're writing a high-performance userspace application, there's a good chance you don't want to deal with handling an error in every single place where your code allocates. I think Rust made the right choice, even though it means some growing pains as it starts being used in kernels
I usually write my programs to only grab a little more memory than is actually needed so I might play around with this at home. I wonder if this has lead to a culture of grabbing more memory than is actually needed since mallocs only fail at large values if everything is set the traditional way.
Defaulting to overcommit seems risky. I'd much rather the system tell me no more memory is available than just having something segfault. I could always wait a bit and try again or something or at the very least shut down the program in a controlled manner.
* exec
* some tools or even libs map gigantic area of anon mem but only touch few bits of it.
However, I stopped using vm.overcommit_memory=2 because the i915 driver has something called the GEM shrinker, and that never runs in that mode. That means all memory ends up going to the driver over time, and other allocations fail eventually. Other parts of the graphics stack do not handle malloc failures gracefully, either. In my experience, that meant I got many more desktop crashes in mode 2 than in the default mode with the usual kernel OOM handler and its forced process termination.
The thing is that ironically, a browser engine is only marginally inside the Rust's niche. (Or maybe it's even marginally outside, at this point I don't think anybody knows.) And for most things things that fit squarely at the focus of the language, it is a bad choice.
The alloc crate came later, and the custom allocator too and is not even stable yet.
https://doc.rust-lang.org/std/alloc/index.html#the-global_al...
But the entire value proposition of Rust is reliability and predictability. Use this in critical applocations. And this is the first time this language is being used in a major Os.
The fact that these changes weren't accepted is not a good sign.
In addition, Rust doesn't require you to use allocation, ever. It was originally expected that users who can't handle allocation failures would eschew libstd in favor of libcore (a subset of libstd with all the allocating parts removed).
Sorry to be pedantic, but that's not really the case: https://en.wikipedia.org/wiki/Rust_for_Linux