7 ms·

well, as an example, Vec::push doesn't have a way to report allocation failure. it will just panic, which is not acceptable in the kernel.

• imglorp 9mo ago
  That seems like an enormous question. Is anyone working on it?
  • pixelesque 9mo ago
    There's experimental/nightly support for things like: `push_within_capacity()` which is a more manual way (user-space code would have to handle the return code and then increase the capacity manually if required) of trying to handle that situation.
    • tialaramex 9mo ago
      And of course the kernel - which doesn't even use Rust's Vec but has its own entire allocator library because it is the kernel - likewise provides https://rust.docs.kernel.org/next/kernel/alloc/kvec/struct.Vec.html#method.push_within_capacity https://rust.docs.kernel.org/next/kernel/alloc/kvec/struct.V... Vec::push_within_capacity is a nice API to confront the reality of running out of memory. "Clever" ideas that don't actually work are obviously ineffective once we see this API. We need to do something with this T, we can't just say "Somebody else should ensure I have room to store it" because it's too late now. Here's your T back, there was no more space.
• kibwen 9mo ago
  Sure, which is a perfectly acceptable default considering that most code is not in a position to observe allocation failures (because of OS-level overcommit, which is nearly always a good thing), and furthermore most code is not in a position to do anything other than crash in an OOM scenario. If you still want to have control over this without going full no_std, Rust has Vec::try_reserve to grow a Vec while checking for allocation errors, as well as several nightly functions coming down the pipe in the same vein (e.g. Vec::try_with_capacity, Vec::push_within_capacity).
  • koakuma-chan 9mo ago
    I think this is bullshit. If you are running out of memory, you can, for example, choose to stop accepting more work ("backpressure"). I am always advocating for Rust, but this is one thing I really disagree on. I think Zig gets this right.
    • ViewTrick1002 9mo ago
      Now you need to ensure that your entire error path does not allocate or you have to deal with allocation errors in the error path as well. Trying to apply backpressure from memory allocation failures which can appear anywhere completely disconnected from their source rather than capping the current in memory set seems like an incredibly hard path to make work reliably.
      • smj-edison 9mo ago
        In Zig's case, the entire stdlib never allocates on failure, and most libraries follow the same pattern. The philosophy of Zig is allocation/creation can fail, but freeing/destroying must never fail. It's caused me to be really thoughtful with how I design my data structures, and often made me use better ways of representing metadata.
        • ViewTrick1002 9mo ago
          How do you log or tell the world about the state of the program without allocating?
          • koakuma-chan 9mo ago
            You don't have to allocate to print to stdout if that's what you're asking.
            • ViewTrick1002 9mo ago
              And then whatever thing that is collecting and forwarding(if applicable) the logs needs to be entirely allocation free?
• ziml77 9mo ago
  That's why you don't use std in this case. You limit yourself to things defined in core.