6 ms·

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, wh

by kibwen 10mo 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 10mo 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 10mo 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 10mo 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 10mo ago
      How do you log or tell the world about the state of the program without allocating?
      - koakuma-chan 10mo ago
        You don't have to allocate to print to stdout if that's what you're asking.
        ViewTrick1002 10mo ago
        And then whatever thing that is collecting and forwarding(if applicable) the logs needs to be entirely allocation free?
        ncruces 10mo ago
        It just needs to have whatever memory it needs statically allocated.
      - smj-edison 10mo ago
        Well if you've hit OOM, you're kinda screwed anyways. But, if you allocate a ring buffer at the beginning, you can always do a best attempt write.
        koakuma-chan 10mo ago
        Why screwed? It could just be that there is more load than your application can handle. Why should it necessarily crash because of that?
        orf 10mo ago
        You need to apply backpressure before you hit memory limits, not after. If you’re OOM your application is in a pretty unrecoverable state. Theoretically possible, practically not.
  - throw-qqqqq 10mo 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 And that is usually not too difficult in C (in my experience), where allocation is explicit. In C++, on the other hand, this quickly gets hairy IMO.
asveikau 10mo ago
I used to think this way many years ago, then I saw my own code in production hit OOM errors and manage to recover, and even log what was happening so I could read about it later. After those experiences I agree with the sibling comment that calls your position "bullshit". I think people come to your conclusion when they haven't experienced a system that can handle it, so they're biased to think it's impossible to do. Since being able to handle it is not the default in so many languages and one very prominent OS, fewer people understand it is possible.
lelanthran 10mo ago
> most code is not in a position to do anything other than crash in an OOM scenario. That's intentional; IOW the "most code" that is unable to handle OOM conditions are written that way. You can write code that handles OOM conditions gracefully, but that way of writing code is the default only in C. In every other language you need to go off the beaten path to gracefully handle OOM conditions.
- gpm 10mo ago
  Handling OOM gracefully - i.e. doing anything other than immediately crashing and/or invoking undefined behaviour - is absolutely not the default in C. It's possible. But very very few projects do.
  - lelanthran 10mo ago
    > Handling OOM gracefully - i.e. doing anything other than immediately crashing and/or invoking undefined behaviour - is absolutely not the default in C. What are you talking about? Every allocation must be checked at the point of allocation, which is "the default" If you write non-idiomatically, then sure, in other languages you can jump through a couple of hoops and check every allocation, but that's not the default. The default in C is to return an error when allocation fails. The default in C++, Rust, etc is to throw an exception. The idiomatic way in C++, etc is to not handle that exception.
    - gpm 10mo ago
      > Every allocation must be checked at the point of allocation, which is "the default" C doesn't force you to check the allocation at all. The default behavior is to simply invoke undefined behavior the first time you use the returned allocation if it failed. In practice I've found most people write their own wrappers around malloc that at least crash - for example: https://docs.gtk.org/glib/memory.html https://docs.gtk.org/glib/memory.html PS. The current default in rust to print something and then abort the program, not panic (i.e. not throw an exception). Though the standard library reserves the right to change that to a panic in the future.
samiv 10mo ago
Talking as a long time C++ programmer. I really don't get this mind set. First off allocation failure (typically indicated by bad_alloc exception in C++ code, or nullptr in C style code) does not mean that the system (or even the process) as a whole is out of memory. It just means that this particular allocator could not satisfy the allocation request. The allocator could have "ulimit" or such limit that is completely independent from actual process/system limitations. Secondarily what reason is there to make an allocation failure any different than any other resource allocation failure? A normal structure for a program is to catch these exceptions at a higher level in the stack close to some logical entry point, such as thread entry point, UI action handler etc. where they can be understood and possibly shown to the user or logged or whatever. It shouldn't really matter if the failure is about failing to allocate socket or failing to allocate memory. You could make the case that if the system is out of memory the exception propagation itself is going to fail. Maybe..but IMHO on the code path that is taken when stack is unwound due to exception you should only release resources not allocate more anyway.
- TZubiri 10mo ago
  >does not mean that the system is out of memory. >"The allocator could have "ulimit" or such limit that is completely independent from actual process/system limitations." Are we playing word games here? If a process has a set amount of memory, and it's out of it, then that process is OOM, if a VM is out of memory, it's OOM. Yes, OOM is typically used for OS OOM, and Linus is talking about rust in the kernel, so that's what OOM would mean. >Secondarily what reason is there to make an allocation failure any different than any other resource allocation failure. Of course there is, would you treat being out of bread similar to being out of oxygen? Again this can be explained by the context being kernel development and not application development.
  - samiv 10mo ago
    "Are we playing word games here? If a process has a set amount of memory, and it's out of it, then that process is OOM, if a VM is out of memory, it's OOM. Yes, OOM is typically used for OS OOM, and Linus is talking about rust in the kernel, so that's what OOM would mean." As I just explained an allocator can have its own limits. A process can have multiple allocators. There's no direct logical step that says that because some allocator some failed some allocation, the process itself cannot allocate more ever. "Of course there is, would you treat being out of bread similar to being out of oxygen? Again this can be explained by the context being kernel development and not application development." The parent comment is talking about over commitment and OOM as if these are situations that are completely out of the programs control. They aren't.

by kibwen 10mo ago

koakuma-chan 10mo 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 10mo 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 10mo 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 10mo ago
    How do you log or tell the world about the state of the program without allocating?
    - koakuma-chan 10mo ago
      You don't have to allocate to print to stdout if that's what you're asking.
      - ViewTrick1002 10mo ago
        And then whatever thing that is collecting and forwarding(if applicable) the logs needs to be entirely allocation free?
        ncruces 10mo ago
        It just needs to have whatever memory it needs statically allocated.
    - smj-edison 10mo ago
      Well if you've hit OOM, you're kinda screwed anyways. But, if you allocate a ring buffer at the beginning, you can always do a best attempt write.
      - koakuma-chan 10mo ago
        Why screwed? It could just be that there is more load than your application can handle. Why should it necessarily crash because of that?
        orf 10mo ago
        You need to apply backpressure before you hit memory limits, not after. If you’re OOM your application is in a pretty unrecoverable state. Theoretically possible, practically not.
- throw-qqqqq 10mo 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 And that is usually not too difficult in C (in my experience), where allocation is explicit. In C++, on the other hand, this quickly gets hairy IMO.

asveikau 10mo ago

I used to think this way many years ago, then I saw my own code in production hit OOM errors and manage to recover, and even log what was happening so I could read about it later. After those experiences I agree with the sibling comment that calls your position "bullshit". I think people come to your conclusion when they haven't experienced a system that can handle it, so they're biased to think it's impossible to do. Since being able to handle it is not the default in so many languages and one very prominent OS, fewer people understand it is possible.

lelanthran 10mo ago

> most code is not in a position to do anything other than crash in an OOM scenario. That's intentional; IOW the "most code" that is unable to handle OOM conditions are written that way. You can write code that handles OOM conditions gracefully, but that way of writing code is the default only in C. In every other language you need to go off the beaten path to gracefully handle OOM conditions.

gpm 10mo ago
Handling OOM gracefully - i.e. doing anything other than immediately crashing and/or invoking undefined behaviour - is absolutely not the default in C. It's possible. But very very few projects do.
- lelanthran 10mo ago
  > Handling OOM gracefully - i.e. doing anything other than immediately crashing and/or invoking undefined behaviour - is absolutely not the default in C. What are you talking about? Every allocation must be checked at the point of allocation, which is "the default" If you write non-idiomatically, then sure, in other languages you can jump through a couple of hoops and check every allocation, but that's not the default. The default in C is to return an error when allocation fails. The default in C++, Rust, etc is to throw an exception. The idiomatic way in C++, etc is to not handle that exception.
  - gpm 10mo ago
    > Every allocation must be checked at the point of allocation, which is "the default" C doesn't force you to check the allocation at all. The default behavior is to simply invoke undefined behavior the first time you use the returned allocation if it failed. In practice I've found most people write their own wrappers around malloc that at least crash - for example: https://docs.gtk.org/glib/memory.html https://docs.gtk.org/glib/memory.html PS. The current default in rust to print something and then abort the program, not panic (i.e. not throw an exception). Though the standard library reserves the right to change that to a panic in the future.

samiv 10mo ago

Talking as a long time C++ programmer. I really don't get this mind set. First off allocation failure (typically indicated by bad_alloc exception in C++ code, or nullptr in C style code) does not mean that the system (or even the process) as a whole is out of memory. It just means that this particular allocator could not satisfy the allocation request. The allocator could have "ulimit" or such limit that is completely independent from actual process/system limitations. Secondarily what reason is there to make an allocation failure any different than any other resource allocation failure? A normal structure for a program is to catch these exceptions at a higher level in the stack close to some logical entry point, such as thread entry point, UI action handler etc. where they can be understood and possibly shown to the user or logged or whatever. It shouldn't really matter if the failure is about failing to allocate socket or failing to allocate memory. You could make the case that if the system is out of memory the exception propagation itself is going to fail. Maybe..but IMHO on the code path that is taken when stack is unwound due to exception you should only release resources not allocate more anyway.

TZubiri 10mo ago
>does not mean that the system is out of memory. >"The allocator could have "ulimit" or such limit that is completely independent from actual process/system limitations." Are we playing word games here? If a process has a set amount of memory, and it's out of it, then that process is OOM, if a VM is out of memory, it's OOM. Yes, OOM is typically used for OS OOM, and Linus is talking about rust in the kernel, so that's what OOM would mean. >Secondarily what reason is there to make an allocation failure any different than any other resource allocation failure. Of course there is, would you treat being out of bread similar to being out of oxygen? Again this can be explained by the context being kernel development and not application development.
- samiv 10mo ago
  "Are we playing word games here? If a process has a set amount of memory, and it's out of it, then that process is OOM, if a VM is out of memory, it's OOM. Yes, OOM is typically used for OS OOM, and Linus is talking about rust in the kernel, so that's what OOM would mean." As I just explained an allocator can have its own limits. A process can have multiple allocators. There's no direct logical step that says that because some allocator some failed some allocation, the process itself cannot allocate more ever. "Of course there is, would you treat being out of bread similar to being out of oxygen? Again this can be explained by the context being kernel development and not application development." The parent comment is talking about over commitment and OOM as if these are situations that are completely out of the programs control. They aren't.