471–480 of 574 posts
Earlier quoted context omitted.
That is not the official name, and it is highly unlikely that it ever will be in the future.
It's worth pointing out the Department of Defense was named the Department of War for over 150 years, up until 1947. https://en.wikipedia.org/wiki/United_States_Department_of_Wa...
Earlier quoted context omitted.
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.
Why screwed? It could just be that there is more load than your application can handle. Why should it necessarily crash because of that?
I was suggesting (though in retrospect not clearly) that logging should use a ring buffer instead of allocation, in order to make logging on cleanup a guaranteed best effort operation. You're right that you can recover from OOM, but logging OOM with an allocator is pretty self-defeating.
Earlier quoted context omitted.
Why is glue code not normal code in Rust? I don't think anyone else would say that for any other language out there. Does it physically pain you to admit it's a bug in Rust code? I write bugs in all kind of languages and never feel the need for adjectives like "technical", "normal", "everyday" or words like "outlier" to make me feel not let down by the language of choice.
I have worked with Rust for ~3.5 years. I had to use the `unsafe` keyword, twice. In that context it's definitely not everyday code. Hence it's difficult to use that to gauge the language and the ecosystem. Of course it's a bug in Rust code. It's just not a bug that you would have to protect against often in most workplaces. I probably would have allowed that bug easily because it's not something I stumble upon more…
Earlier quoted context omitted.
I have worked with Rust for ~3.5 years. I had to use the `unsafe` keyword, twice. In that context it's definitely not everyday code. Hence it's difficult to use that to gauge the language and the ecosystem. Of course it's a bug in Rust code. It's just not a bug that you would have to protect against often in most workplaces. I probably would have allowed that bug easily because it's not something I stumble upon more…
I don't care if there can be a bug in Rust code. It doesn't diminish the language for me. I don't appreciate mental gymnastics when evidence is readily available and your comments come out as compulsive defense of something nobody was really is attacking. I'm sorry for the jest in the comments.
But you and me seem to be much closer in opinion and a stance than I thought. Thanks for clarifying that.
Earlier quoted context omitted.
>> I guess that's at least in part because of the difficulty of building safe, fast and highly-concurrent C applications (please correct me if I'm wrong). You wrote that question in a browser mostly written in C++ language, running on an OS most likely written in C language.
Just because the pyramids exist, it means they were easy to build? OS and browser development are seriously hard and took countless expert man hours.
Earlier quoted context omitted.
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…
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 completel…
So I assume there is no real blockers as people in this tread assume, this is just not a conventional behavior, ad hoc, so we need to wait and well defined stable OOM handlers will appear
Earlier quoted context omitted.
There are several levels here. In your C++ (or C) program you have one (or more) allocators. These are just pieces of code that juggle blocks of memory into smaller chunks for the program to use. Typically the allocators get their memory from the OS in pages using some OS system call such as sbrk or mmap. For the sake of argument, let's say I write an allocator that has a limit of 2MiB, while my system has 64Gib or R…
None of that matters: what is your application going to do if it tries to allocate 3mb of data from your 2mb allocator? This is the far more meaningful part of the original comment: > and furthermore most code is not in a position to do anything other than crash in an OOM scenario Given that (unlike a language such as Zig) Rust doesn’t use a variety of different allocator types within a given system, choosing to reli…
If some allocation fails, the error bubbles up until a safe place, where some pages can be dropped from the cache, and the operation that failed can be tried again.
All this requires is that bubbling up this specific error condition doesn't allocate. Which SQLite purportedly tests.
I'll note that this is not entirely dissimilar to a system where an allocation that can't be immediately satisfied triggers a full garbage collection cycle before an OOM is raised (and where some data might be held through soft/weak pointers and dropped under pressure), just implemented in library code.
Earlier quoted context omitted.
There are several levels here. In your C++ (or C) program you have one (or more) allocators. These are just pieces of code that juggle blocks of memory into smaller chunks for the program to use. Typically the allocators get their memory from the OS in pages using some OS system call such as sbrk or mmap. For the sake of argument, let's say I write an allocator that has a limit of 2MiB, while my system has 64Gib or R…
None of that matters: what is your application going to do if it tries to allocate 3mb of data from your 2mb allocator? This is the far more meaningful part of the original comment: > and furthermore most code is not in a position to do anything other than crash in an OOM scenario Given that (unlike a language such as Zig) Rust doesn’t use a variety of different allocator types within a given system, choosing to reli…
Historically, a lot of C code fails to handle memory allocation failure properly because checking malloc etc for null result is too much work — C code tends to calm that a lot.
Bjarne Stroustrup added exceptions to C++ in part so that you could write programs that easily recover when memory allocation fails - that was the original motivation for exceptions.
In this one way, rust is a step backwards towards C. I hope that rust comes up with a better story around this, because in some applications it does matter.
Earlier quoted context omitted.
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.
If you allocate a relatively big chunk of memory for each unit of work, and at some point your allocation fails, you can just drop that unit of work. What is not practical?
I suppose you can try to reliable target "seriously wild allocation fails" without leaving too much memory on the table.
0: Heuristic overcommit handling. Obvious overcommits of
address space are refused. Used for a typical system. It
ensures a seriously wild allocation fails while allowing
overcommit to reduce swap usage. root is allowed to
allocate slightly more memory in this mode. This is the
default.
Running in an environent without overcommit would allow you to handle it gracefully though, although bringing its own zoo of nasty footguns.
See this recent discussion on what can happen when turning off overcommit: