(no title)
abendstolz | 4 years ago
So for `Rust for Linux` they also need to implement a `Result-like` type that is stack only based to solve this issue, right?
If so, cool, thanks, you just made my day by tickling my learning nerves! :)
abendstolz | 4 years ago
So for `Rust for Linux` they also need to implement a `Result-like` type that is stack only based to solve this issue, right?
If so, cool, thanks, you just made my day by tickling my learning nerves! :)
cormacrelf|4 years ago
It actually has to do with `panic!(...)`. When you use `unwrap()`/`expect("...")`, you use the panic macro under the hood; parts of the panicking infrastructure use a boxed trait object which could contain a static string or formatted String or anything else really. The box can allocate if it is not a ZST. I believe the alloc crate's default handler tries to avoid this kind of thing, so that it can't fail to allocate AGAIN in the failure-handling routine. It will likely do a better job than you could.
This is a live issue at the moment, so to go into any more detail I'd have to read a bunch of recent Rust issues/PRs.
cormacrelf|4 years ago
They can kill entire misbehaving processes. What are you going to do in your little program, clear a cache whose objects are sprinkled evenly across 150 different pages? You would need more control than you get from blindly using malloc/free/rust_alloc globally. Something like memcached would be able to use these APIs, because it uses its own allocator, and knows enough about its layout to predictably free entire pages at once.
abendstolz|4 years ago
bluejekyll|4 years ago
The Error type currently isn’t in core, but for other reasons, that just got resolved: https://twitter.com/bascule/status/1452029363197784071?s=21