3 ms·
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 back
by 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 agoIn 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 agoHow do you log or tell the world about the state of the program without allocating?
- koakuma-chan 9mo agoYou don't have to allocate to print to stdout if that's what you're asking.
- ViewTrick1002 9mo agoAnd then whatever thing that is collecting and forwarding(if applicable) the logs needs to be entirely allocation free?
- ncruces 9mo agoIt just needs to have whatever memory it needs statically allocated.
- smj-edison 9mo agoWell 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 9mo agoWhy screwed? It could just be that there is more load than your application can handle. Why should it necessarily crash because of that?
- orf 9mo agoYou 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.
- koakuma-chan 9mo agoIf 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?
- ViewTrick1002 9mo agoI think in that case overcommit will happily say the allocation worked. Unless you also zero the entire chunk of memory and then get OOM killed on the write. 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. https://www.kernel.org/doc/Documentation/vm/overcommit-accounting https://www.kernel.org/doc/Documentation/vm/overcommit-accou... 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: https://news.ycombinator.com/item?id=46300411 https://news.ycombinator.com/item?id=46300411
- Brian_K_White 9mo agoGood grief all kinds of ways. Practically all the same countless possible paths as those that require allocating.
- throw-qqqqq 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 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.