Allocation failure should panic

OOM is one failure that Rust deliberately doesn’t even try to recover from.

The commonly imagined scenario (apart from outright dismissal based on assumption that everyone runs Linux with overcommit) is that when allocation failure happens, the memory is totally absolutely full, so full that it may not even be possible to allocate 100 bytes of memory for the error message.

But the common scenario that I run into is that I have a server with 500MB of RAM free, and tell it to allocate 2GB of RAM. The allocation fails, but in this OOM situation I still have 500MB of RAM free, which is plenty enough to gracefully unwind the offending thread.

Please, can you let Rust at least try to recover from OOM? Not every failure is recoverable, but those that are, are important for me.

In web servers it’s OK to kill one thread handling a bad request, but it’s very undesirable to suddenly kill the whole server and throw away work of all requests in flight just because one of the requests did something stupid.

This unreliability-by-design is stopping me from adopting Rust for web services.

4 Likes

Some relevant issues:

rfcs/text/1398-kinds-of-allocators.md at master · rust-lang/rfcs · GitHub and its tracking issue Allocator traits and std::heap · Issue #32838 · rust-lang/rust · GitHub -- this one is the most interesting, since it specifies:

The Allocator trait ... All methods that can fail to satisfy a request return a Result (rather than building in an assumption that they panic or abort).

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.