Understanding async cancelation

⚓ Rust    📅 2025-10-08    👤 surdeus    👁️ 4      

surdeus

I watched the rust conference video on async cancelation safety and it made me wonder if there is a better way.

It seems to me like the rusty approach to this would be the Undroppable traits that were mentioned combined with all the combinators (like select!) returning the unfinished futures. This would force cancelation unsafe futures to be processed to completion.

Is there a reason select! calls and such don't return the unfinished futures? I realize this would be much more verbose, but it feels like there are too many footguns in async otherwise.

For the undroppable futures they could implement a cancel trait. For example the channel that loses the message when canceled, could instead implement cancel by returning the message back to the caller. This would consume the future without dropping it, and there would be no cancelation issues.

You could wrap an undroppable trait in a Cancelation future that provides the behavior on drop such as discarding the unsent channels message, or caching it for later.

Thoughts? Is there anything I am missing for why this sort of approach isn't taken?

1 post - 1 participant

Read full topic

🏷️ Rust_feed