from Hacker News

Asynchronous clean-up

by hermanradtke on 2/25/24, 2:37 AM with 70 comments

• by jandrewrogers on 2/25/24, 6:35 AM

  This post is primarily about Rust but the issues raised generalize to async models in any programming language. The tradeoffs between approaches are severe enough that it is desirable, at least in a systems language, to preserve enough flexibility that the model generalizes to different contexts without loss of performance or robustness. Furthermore, async tends to erode modularity in code because async behavior, which is tightly coupled to internal design choices, becomes part of the functional contract. There are all kinds of interesting edge cases around things like bounding worst-case resource pseudo-leakage that you simply don’t need to think about in synchronous code.

  This is not to suggest that async models are a bad idea. They just have a higher level of intrinsic complexity and language support is immature. The benefit is qualitatively better scalability and performance, so there is a purpose behind using async models.

• by pdimitar on 2/25/24, 7:39 AM

  I am likely not even at 10% of the competence of the author but I can't help but notice the continuously mentioned struggle of "but what if we cancel the cancellation?" -- which to me seems to be the wrong question to ask. IMO it should not be possible. It should be made impossible by the compiler. The "everything is cancellable" rabbit hole is infinite and is not worth pursuing. Eventually the Rust core team will be inspecting CPU microcode and its bugs, or what's the endgame exactly? So let's not go there, I say.

  I know that Rust does not have a runtime and it does not have a spec but I think the questions posed in the article hint at the need for either -- or even both at the same time (i.e. "make a spec for the third party runtime implementors").

  I am not saying "imitate Golang or Erlang". I am saying: "just pick a side already".

  On a more intuitive level: to me it feels like Rust tries to be everything for everyone, and I think many of us know that will never work.

  Choose. Commit. Double down. Make it work. Golang and Erlang did. Rust can do it as well.

• by u320 on 2/25/24, 9:00 AM

  Reading about async Rust is like reading about a large complicated infrastructure project that keeps getting delays and cost overruns. Rust will end up spending a significant part of its complexity budget on async alone. I wonder if it's worth it, for a problem that gets significantly easier if you are prepared to be just a bit more wasteful (allocations, memory, etc). Compare with Ocaml or Haskell for instance.

• by georgelyon on 2/25/24, 5:49 AM

  I’ve been following a similar issue in Swift (which is informed by some learnings from the Rust side of things). Here is a link to the latest language complexity resulting from this: https://forums.swift.org/t/sub-pitch-task-local-values-in-is...

  There are a number of other proposals linked to this issue that can be referenced from that thread. I hope there is a next generation async model for future languages that is truly simple, because this all makes me think footguns are endemic to the current approach (which is broadly the same in Rust and Swift).

• by feverzsj on 2/25/24, 7:19 AM

  Seems java's virtual thread is the only sane async model out there.

• by lordmauve on 2/26/24, 7:16 AM

  > I would be interested in examples of code that users believe require cancellation-specific async code, though.

  This happens all the time. For example, cancellation in the middle of sending a HTTP request. The connection is now unusable and must be closed. Without cancellation the connection returns to a state where it can be used and is re-added to a pool.

• by PoignardAzur on 2/25/24, 12:22 PM

  > On a UNIX system, the file is closed in the call to drop by calling close(2). What happens if that call returns an error? The standard library ignores it. This is partly because there’s not much you can do to respond to close(2) erroring, as a comment in the standard library elucidates

  Note that this is true for UNIX file descriptors, but not for C++ streams: an error when closing may indicate that the stream you closed had some buffered data it failed to flush (for any of the reasons that a failed write might come from).

  In that case, you sometimes do want to take a different codepath to avoid data loss; eg, if your database does "copy file X to new file Y, then remove X", if closing/flushing Y fails then you absolutely want to abort removing X.

  In the case of Rust code, the method you want is `File::sync_all`, which returns a Result for this exact purpose.

• by hardwaresofton on 2/25/24, 11:26 AM

  In the meantime I actually wrote a create that hacks around this problem:

  https://crates.io/crates/async-dropper

• by asabil on 2/25/24, 2:20 PM

  > I don’t have an example of fully non-cooperative cancellation available off the top of my head.

  That would be Erlang.

• by ggreg84 on 2/25/24, 4:12 PM

  Asynchronous clean-up is a solved problem in C++ senders & receivers.

  I wonder what's so different about rust that they can't solve it in the same way.

• by 38 on 2/25/24, 6:27 AM

  > I can write all these posts and tell you with a straight face there’s no tradeoff because appeasing the borrow checker is NBD. I never think about appeasing the borrow checker when I write Rust.

  Guy is in a bubble. He doesn't realize that 99% of rust programmers don't have the experience he does.