121–130 of 165 posts
Earlier quoted context omitted.
I guess you pre-allocate these UI elements when you start your application.
What if malloc fails at that point because some other application (we're in a preemptive multitasking OS) decided to gobble up all RAM?
This assumption lead to Rust's standard library not having a way to catch allocation failures (which is only now being rectified, and only partially). It's very Linux-centric and presumes a certain config+usage pattern. Not true on Windows. Not quite true on macOS. Not true in WASM. Definitely not true on embedded platforms.
When I use Python sometimes I run into a MemoryError when working with large datasets. How does the Python runtime know I am out of memory if the kernel won't tell it. Does it try a write and catch the signal?
What bothers me is that I read this train wreck without any red flags until I saw his correction at the end. Even the headline was wrong given the article, which itself was wrong. I really should have coffee before HN
What exactly is "wrong" about the article? Linux's Overcommit behavior is non-obvious to many programmers. Its one of those issues that very few programmers I've come across in the workplace understand properly. This blogpost properly understands the issues associated with Overcommit, and have done some preliminary investigations that describe the behavior. Its a really good blogpost. The general point of the blogpos…
Earlier quoted context omitted.
If you take a look at the Linux kernel, a hugely complex and sophisticated piece of software, you'll find that it gracefully handles allocation failures.
The kernel's "graceful handling" of allocation failures includes killing unrelated processes in an attempt to free some memory.
Earlier quoted context omitted.
> It's worth pointing out that if you turn overcommit off ... you will, in fact, get this guarantee But many Linux applications assume the overcommit behavior. Its far easier to just "go with the flow" or "When in Rome...". Overcommit is the programming culture of Linux and should be assumed when writing Linux apps.
That has not been my experience. I disable overcommit on my machines and it has been considerably nicer to have apps exit due to malloc failing than random processes getting OOM-killed.
malloc fails with ulimit
Very relevant, because containers are often under what basically is ulimit. Not that you can do much when malloc fails...
Earlier quoted context omitted.
> Unless you are working in something like a medical or nuclear device, it is not worth to bother with such things. Where "something like a medical or nuclear device" implies a piece of software that is expected to work correctly. In other words, you should always ensure that failures resulting from malloc(3) returning an error (and all other errors) are suitably contained.
No, i did not implied that, please do not put words in my mouth. My implication was software that if it fails it will kill people. Otherwise if a program crashes because of a situation happens once every 100000000 runs, not only is worthless to worry about it, it actually is preferable to not do that as to keep the codebase clean and hence easier to maintain for bugs that actually do affect people.
How does one guarantee that allocated memory is real? Can you easily wrap malloc to zero/poke the memory in a way that catches all exceptions and guarantees yay or nay ?