No-Panic Rust: A Nice Technique for Systems Programming • Hacker News Board

Re: No-Panic Rust: A Nice Technique for Systems Programming

#141

Post by dathinab » Fri, Feb 07, 2025, 7:48 AM UTC

sunshowers wrote: post #140

dathinab wrote: post #139

Earlier quoted context omitted.

I know some do. But as long as you don't do anything unusual you are basically introducing a (potentially huge) availability risk to your service for no reason but except not liking panics. Like it's now enough for there to be a single subtle bug causing a panic to have a potentially pretty trivially exploitable and cheap DoS attack vector. Worse this might even happen accidentally. Turning a situation where some end…

Well, no it's not just not liking panics — it's that panics can leave memory in an inconsistent state. std::sync::Mutex does poisoning, but many other mutexes don't. And beyond that, you could also panic in the middle of operating on an &mut T, while state is invalid. Tearing down the entire process tends to be a pretty safe alternative.

> but many other mutexes don't.

yes and that's most times the better design decision

> operating on an &mut T, while state is invalid.

but you normally don't and for many use cases is in my experiment a non-issue

panic recovery isn't fine grained and passing `&mut T` data across recovery boundaries is bothersome

at the same time most of the cross request handler in-memory state is stuff like caches and similar which as long as you don't hand role them should work just fine with panic recovery

At the same time deciding to not recover some kinds of shared state and recreate them isn't hard at all, at least assuming no spaghetti code with ton's of `static` globals are used.

And sure there are some use cases where you might prefer to tear down the process, but most web-server use cases aren't anywhere close to it in my experience. I can't remember having had a single bug because of panic recovery in the last like ~8?? years of using it in production (yes a company I previous worked for started using it in production around it's 1.0 release).

EDIT: Actually I correct myself 2 bugs. One due to Muxtex poison which wouldn't have been a problem if the Muxtex didn't had poison. And another due to a certain SQL library insisting of not fixing a long standing bug by insisting on reexport a old version of a crate known to be broken which had been fixed upstream because they didn't like the way it was fixed and both not documenting that you can't use it with panic recovery and closing all related issues because "if you use panics you are dump".

But both of them where like 6-8 years ago.

Re: No-Panic Rust: A Nice Technique for Systems Programming

#142

Post by sieabahlpark » Fri, Feb 07, 2025, 4:26 PM UTC

nicce wrote: post #112

dathinab wrote: post #108

Earlier quoted context omitted.

> I would say that you are using them incorrectly if you assume them as recoverable. no it's them being recoverable at well defined boundaries is a _fundamental_ design aspect of rust > Overhead comes from the cleaning process. If you don't clean properly, you might leak information or allocate more resources than you should. and that same cleanup process makes it recoverable

Even the book uses the word "unrecoverable". The wording is communication. The intention is not to recover them, while it could be possible. https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-...

[dead]

Re: No-Panic Rust: A Nice Technique for Systems Programming

#143

Post by vlovich123 » Fri, Feb 07, 2025, 6:50 PM UTC

haberman wrote: post #135

vlovich123 wrote: post #118

Earlier quoted context omitted.

To be clear as there’s a lot of nuance. Assert unchecked is telling the compiler the condition must always hold. The optimizer and compiler don’t make any assumption about the assert. That information is then used by the compiler to optimize away checks it otherwise would have to do (eg making sure an Option is Some if you call unwrap). If you have an assumption that gives unhelpful information, the optimizer will em…

> Wrapping it in a safe call as in this article would have been unthinkable - the unsafe needs to live exactly where you are making the assumption, there’s no safety provided by the wrapper. I want to be sure I understand your meaning. In your analysis, if the check_invariant function was marked unsafe, would the code be acceptable in your eyes?

Unsafe is the P0. I'd avoid this approach wholesale UNLESS it was a critical hot path with no other way to get safe Rust to elide the check (hint - you'd be surprised how much gets elided in idiomatic Rust). Basically, this is a nice sharp knife in the toolbox to know about and so sharp I'd rarely use it.