Like you, I believe that unwinding from OOM is an important use case for user-space. I also believe that there needs to be a library that exposes
Result<> based APIs for allocation, for use in freestanding environments.
I think that aborting on OOM is not reasonable in general. It is reasonable in some situations, such as for client-side programs that should never, ever run out of memory, or for servers that can simply be restarted.
Note that not every language supports recovering from OOM. Perl doesn't by default, and Go and GHC Haskell both treat OOM as fatal. Furthermore, parts of
glibc exit the process on OOM!
As far as your image processing server is concerned, you can implement a custom allocator that panics when it runs out of memory. If you do that, expect to file bugs against the unsafe code in
libstd for not being robust in such situations. Alternatively, you can keep track of all memory in use, and fail requests that will use too much memory. The user of the server can pass the amount of memory available as a parameter at server startup. Finally, note that you can write your application without the standard library – even
#![no_std] Rust is still much, much better than C.
My suggestion, if you have time, is to write a library yourself that handles OOM as you desire.
libstd is by no means magical: it is entirely ordinary Rust code (possibly with a small amount of C and assembler, though I am not sure if there is any). You most definitely can implement the parts you need yourself, and they WILL work (assuming you implemented them correctly). I promise you that you are not the only one wanting this – people writing Rust in kernel mode do too, so you should be able to get contributions. Try talking to the Redox project.