←back to thread

Futurelock: A subtle risk in async Rust

(rfd.shared.oxide.computer)
431 points bcantrill | 1 comments | 31 Oct 25 16:49 UTC | HN request time: 0.216s | source

This RFD describes our distillation of a really gnarly issue that we hit in the Oxide control plane.[0] Not unlike our discovery of the async cancellation issue[1][2][3], this is larger than the issue itself -- and worse, the program that hits futurelock is correct from the programmer's point of view. Fortunately, the surface area here is smaller than that of async cancellation and the conditions required to hit it can be relatively easily mitigated. Still, this is a pretty deep issue -- and something that took some very seasoned Rust hands quite a while to find.

[0] https://github.com/oxidecomputer/omicron/issues/9259

[1] https://rfd.shared.oxide.computer/rfd/397

[2] https://rfd.shared.oxide.computer/rfd/400

[3] https://www.youtube.com/watch?v=zrv5Cy1R7r4

Show context
samdoesnothing ◴[01 Nov 25 06:46 UTC] No.45779692[source]▶
LOL. All the Rust evangelists talk about safety when stuff like this exists? JFC. Can we stop calling Rust safe now? Finally? I mean we all know deep in our hearts that trivial memory safety doesn't mean programs are correct or "safe" by any means but its nice to have proof that Rust is fundamentally unsafe for asynchronous tasks at least. Or at least "unsound".

Structured concurrency will always win IMO.

replies(1): >>45779801 #
mustache_kimono ◴[01 Nov 25 07:17 UTC] No.45779801[source]▶
> All the Rust evangelists talk about safety when stuff like this exists? JFC.

Deadlocks can happen anywhere? You can replicate this pattern in golang.

replies(2): >>45783525 #>>45785181 #
1. samdoesnothing ◴[01 Nov 25 20:46 UTC] No.45785181[source]▶
Golang doesn't have legions of evangelicals claiming it's a safe language and everything should be written in it.