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.
Async Rust code is currently well-suited to both web servers and embedded. I, for one, would be very sad if they "just picked a side" that excluded one of these (very different) use cases.
Being automatically cancellable is part of the value proposition of the future abstraction: it lets you abandon unnecessary work automatically. This post is about a limitation on cancellation (cancellation itself must be synchronous).
To me, your comment appears to be a sort of vibey free word association. Microcodes? Pick a side? What on earth are you actually trying to express??
I believe what they're trying to get at is related to the following quote from your article:
This also alleviates the need for considering any sort of question about “what happens if you cancel the cancellation future,” and whether that is recursive or idempotent: once a future begins canceling, “canceling” it again is idempotent, because its already canceling; there is no second future to cancel.
I think the misunderstanding they had is that what you call "async cancellation" requires a second future (which is implicitly constructed from `poll_cancel` or something like that), whose entirely purpose is to run the cancellation code of the first future. If this were the case, then we'd have to ask the question "What happens if the cancellation future is cancelled? Who cleans up after it?"
I don't have enough experience with async Rust in practice yet (sadly), so I was also tripped up when reading at first. I think that you call it "async cancellation" makes people think that it's a separate future, even though (from the type signature of `poll_cancel`) it should be completely clear that it isn't.
Sorry, I hope I got everything right, and that this clears up what I believe to be the misunderstanding for everyone involved!
The design in Eric Holk's post that I link has that property because it has an `on_cancel` combinator to add a future to run when another future is cancelled (and anticipates the problem of then cancelling that future and so on); that section of my post is just about why I wouldn't have that combinator and how if you don't, this problem doesn't exist.
I was mostly trying to express that chasing after everything being cancelable is IMO not worth it i.e. cancelling the destructor code should not ever happen -- the compiler / runtime should not allow it ever.
Again, my opinion only. Feels like too much complexity for no payoff.
The other person replying to you understood me correctly.
Comments
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.
Async Rust code is currently well-suited to both web servers and embedded. I, for one, would be very sad if they "just picked a side" that excluded one of these (very different) use cases.
Yeah, I literally do both, and it's sweet as hell.
Nowhere did I imply I want to take stuff from people. You could have read my comment charitably and without the unnecessary snark.
Check my other sibling comment where I reply to the OP's author.
I'm not sure where you read snark in my comment, but I can assure you it was unintentional.
Well, the quotes when saying:
...did not help.
And again, my comment was more generic and I even explained why: because I can't claim the level of competence of OP's author.
I cannot follow your comment.
Being automatically cancellable is part of the value proposition of the future abstraction: it lets you abandon unnecessary work automatically. This post is about a limitation on cancellation (cancellation itself must be synchronous).
To me, your comment appears to be a sort of vibey free word association. Microcodes? Pick a side? What on earth are you actually trying to express??
I believe what they're trying to get at is related to the following quote from your article:
I think the misunderstanding they had is that what you call "async cancellation" requires a second future (which is implicitly constructed from `poll_cancel` or something like that), whose entirely purpose is to run the cancellation code of the first future. If this were the case, then we'd have to ask the question "What happens if the cancellation future is cancelled? Who cleans up after it?"
I don't have enough experience with async Rust in practice yet (sadly), so I was also tripped up when reading at first. I think that you call it "async cancellation" makes people think that it's a separate future, even though (from the type signature of `poll_cancel`) it should be completely clear that it isn't.
Sorry, I hope I got everything right, and that this clears up what I believe to be the misunderstanding for everyone involved!
The design in Eric Holk's post that I link has that property because it has an `on_cancel` combinator to add a future to run when another future is cancelled (and anticipates the problem of then cancelling that future and so on); that section of my post is just about why I wouldn't have that combinator and how if you don't, this problem doesn't exist.
I was mostly trying to express that chasing after everything being cancelable is IMO not worth it i.e. cancelling the destructor code should not ever happen -- the compiler / runtime should not allow it ever.
Again, my opinion only. Feels like too much complexity for no payoff.
The other person replying to you understood me correctly.