3 ms·

> Being able to panic on OOM won't go back in time and rewrite stdlib I don't see how that's relevant? If you have to deal with OOM you're probably not going t

> Being able to panic on OOM won't go back in time and rewrite stdlib I don't see how that's relevant? If you have to deal with OOM you're probably not going to deal with it at a fine-grained level, you'll have one high-level panic catcher somewhere that handles this and all other panics. Given that overcommit exists as well, this makes the cases where you want workable Result-on-OOM quite niche. (And there is work -- lower priority work, but it exists -- for pluggable allocators which will let the stdlib eventually abstract over more of this)

quotemstr 10y ago
Hundreds of millions of people use non-overcommit systems. That's a good thing, because overcommit is a mistake that encourages profligate use of system resources. I fear that abort-on-OOM will only reinforce the presumption of overcommit in the minds of developers. Even on overcommit systems, you can run out of address space or vsize. I believe in treating memory like any other resource. You wouldn't abort by default when you run out of disk space, would you?
- Manishearth 10y ago
  Overcommit wasn't my main point. My point was that the intersection of systems where: - You are using the stdlib (so not designing an OS or other low level programming) - OOM must be recovered from - OOM-as-panic with recovery at a higher level in the application is not going to work and you need fine grained OOM recovery is small. Overcommit makes it smaller, but ignoring that it is still small.
- lmm 10y ago
  > You wouldn't abort by default when you run out of disk space, would you? If most of the language and standard library required allocating disk space to function then I would indeed abort by default, because very few programs would be able to do anything useful in those conditions, so the most useful thing is to fail fast. It's possible to design a language and standard library that can remain usable in out-of-memory conditions, but the costs would be severe, and not justified for the overwhelming majority of rust use cases, I think.

quotemstr 10y ago

Hundreds of millions of people use non-overcommit systems. That's a good thing, because overcommit is a mistake that encourages profligate use of system resources. I fear that abort-on-OOM will only reinforce the presumption of overcommit in the minds of developers. Even on overcommit systems, you can run out of address space or vsize. I believe in treating memory like any other resource. You wouldn't abort by default when you run out of disk space, would you?

Manishearth 10y ago
Overcommit wasn't my main point. My point was that the intersection of systems where: - You are using the stdlib (so not designing an OS or other low level programming) - OOM must be recovered from - OOM-as-panic with recovery at a higher level in the application is not going to work and you need fine grained OOM recovery is small. Overcommit makes it smaller, but ignoring that it is still small.
lmm 10y ago
> You wouldn't abort by default when you run out of disk space, would you? If most of the language and standard library required allocating disk space to function then I would indeed abort by default, because very few programs would be able to do anything useful in those conditions, so the most useful thing is to fail fast. It's possible to design a language and standard library that can remain usable in out-of-memory conditions, but the costs would be severe, and not justified for the overwhelming majority of rust use cases, I think.