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.
Comments
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.