Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this definition ought to be very precise, I would probably refrain from defining it through the observable effects of future drop + recreate. For example, I would say the following future is cancellation safe under this definition, but just dropping it halfway through the download without driving to the completion can leak disk space:
In my opinion, it is not safe to use this future inside the select! macro, please let me know if you agree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would you define it? Inserting a drop-and-recreate of your future in the middle of a program does change what it does, so in some sense it is not a no-op, even if the difference is not observable until later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, I agree that it may not be considered as a no-op.
I was going to say that I would define it like this: “a future is cancellation safe if and only if creating it and dropping before completion is a no-op”. Now that I think of it, it does not account for losing a place in a fair queue, for example in
Mutex::lock
.Maybe the definition should be more rigorous and state that both create-and-drop and drop-and-recreate should be no-ops (with “no-op” meaning “no observable effects”)? I am not sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I expanded a bit, but I think it's fine as-is.