3 ms·

Rust has provided ways to not abort on oom for a while now.

wahern 10y ago
If by "a while" you mean several months. But, yes, the recent addition of catch_unwind answered one of my biggest gripes with Rust. https://doc.rust-lang.org/std/panic/fn.catch_unwind.html Does anybody know if the standard library allocator aborts the process or throws a catchable exception? When they added catch_unwind they officially split panics into two types: abort panics and unwind panics. Code can choose one or the other when panic'ing. Also, programs can be built in such a way that all panics become aborts. That kind of sucks but it's probably one of the compromises needed to assuage those Rust developers who don't believe it's practical to handle OOM conditions.
- steveklabnik 10y ago
  To be clear, _every_ panic has to have the same implementation; you can't choose unwind vs abort for some panics vs others. The default allocator crate always does an abort, both before and after this change.
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - wahern 10y ago
    When building an app, does changing the default allocator effect all imported libraries? And is that allocator used for boxing, when boxing requires dynamic allocation?
    - steveklabnik 10y ago
      Currently, "the allocator" is global in Rust. That is, the standard library uses liballoc to do all of its heap allocation, and it's liballoc that aborts on OOM. You can of course write code that does anything, including use some other mechanism than liballoc. There's motion on several fronts here: The first, and currently unstable, is swapping out the implementation of liballoc for a different one. (we ship jemalloc and a pass-through to the system allocator with Rust) The second, and currently in the "working on an RFC" phase, is per-object allocators. Both of these are unstable because we're not 100% sure of the interface we want to stabilize yet, it's still a work in progress. > when boxing requires dynamic allocation? Boxing always implies dynamic allocation.

If by "a while" you mean several months. But, yes, the recent addition of catch_unwind answered one of my biggest gripes with Rust. https://doc.rust-lang.org/std/panic/fn.catch_unwind.html Does anybody know if the standard library allocator aborts the process or throws a catchable exception? When they added catch_unwind they officially split panics into two types: abort panics and unwind panics. Code can choose one or the other when panic'ing. Also, programs can be built in such a way that all panics become aborts. That kind of sucks but it's probably one of the compromises needed to assuage those Rust developers who don't believe it's practical to handle OOM conditions.

steveklabnik 10y ago
To be clear, _every_ panic has to have the same implementation; you can't choose unwind vs abort for some panics vs others. The default allocator crate always does an abort, both before and after this change.
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- wahern 10y ago
  When building an app, does changing the default allocator effect all imported libraries? And is that allocator used for boxing, when boxing requires dynamic allocation?
  - steveklabnik 10y ago
    Currently, "the allocator" is global in Rust. That is, the standard library uses liballoc to do all of its heap allocation, and it's liballoc that aborts on OOM. You can of course write code that does anything, including use some other mechanism than liballoc. There's motion on several fronts here: The first, and currently unstable, is swapping out the implementation of liballoc for a different one. (we ship jemalloc and a pass-through to the system allocator with Rust) The second, and currently in the "working on an RFC" phase, is per-object allocators. Both of these are unstable because we're not 100% sure of the interface we want to stabilize yet, it's still a work in progress. > when boxing requires dynamic allocation? Boxing always implies dynamic allocation.