Hacker News new | past | comments | ask | show | jobs | submit login

From second link:

> Obviously on OOM you usually want to abort _something_. It's just not always the entire thread or process.

Surely you want to abort _some dynamic extent_. The fact that it's (currently) a full C thread is an implementation detail that can hopefully be improved. Requiring manual OOM handling on every single operation is not a scalable solution and will lead to bugs due to laziness or fatigue.

Exceptions aren't necessarily bad/evil. A lot has been learned about the challenges of exceptions/conditions/effects. Language designs will evolve to have better versions of what is a foundational idea in the theory of computation.

In the meantime, a try/catch block is only a small macro over thread::spawn, thread::join, thread::catch_panic away. It would be nice if the language supported that without the weight of a full thread.




Rust's OOM handler calls abort(). This kills the process, and cannot be caught.

i.e. to run rust code that uses the standard library without the chance of abort() on low memory, you need to run it in it's own process.


  > you need to run it in it's own process
Assuming that you can detect OOM in userspace at all, which usually isn't the case on Linux (or any other system with overcommit).


huh? you'd notice your child process was exited with SIGABRT.


SIGABRT doesn't necessarily mean OOM, and in any case if you're prepared to monitor child processes for aborts then you'll be perfectly fine with the fact that Rust's default stdlib aborts on OOM, which is the context of this thread.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: