4 ms·

I cannot follow your comment. Being automatically cancellable is part of the value proposition of the future abstraction: it lets you abandon unnecessary work

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??

TwentyPosts 3y ago
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!
- withoutboats3 3y ago
  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.
pdimitar 3y ago
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.

TwentyPosts 3y ago

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!

withoutboats3 3y ago
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.

pdimitar 3y ago

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.