---
title: "Reading notes: A case for CancellationTokens"
tags: reading-club, WG-async
date: 2023-09-21
url: https://hackmd.io/h27_RB3UTpK6V2ao3CntFg
---

# Reading notes: A case for CancellationTokens

Link to document: https://gist.github.com/Matthias247/354941ebcc4d2270d07ff0c6bf066c64

## Async Drop as a method of graceful cancellation under linear rules

Yosh: Under the header [Graceful Cancellation Methods](https://gist.github.com/Matthias247/354941ebcc4d2270d07ff0c6bf066c64#graceful-cancellation-models) there is no mention of "async Drop" as a way of graceful cancellation. ~~In the absence of [true linear types](https://blog.yoshuawuyts.com/linearity-and-control/), every value _must_ be safe to drop - and thus cancel. Imo the goal really ought to be to call code in response to that.~~

_Edit:_ I didn't initially cath that this post assumed we'd be operating under linear rules. It's not stated explicitly in this post, but I assume they're working designing from the point of: ["types which cannot be dropped"](https://blog.yoshuawuyts.com/linearity-and-control) interpretation of linear types. Rather than the: ["types whose destructor is guaranteed to be called"](https://blog.yoshuawuyts.com/linear-types-one-pager) interpretation of linear types.

`fn poll_cancel` feels like it gets closest to this, but I would have liked to see async Drop mentioned here too. Especially since this document appears to have been written after Sabrina Jewson's post on [Async Drop](https://sabrinajewson.org/blog/async-drop). I wrote an additional example on how async-Drop based graceful shutdown could be leveraged for HTTP servers [here](https://hackmd.io/KqASjHfBR6am3z5INtKCJA?view#Example). This would work even for the "drop is guaranteed to be called" interpretation of linear types, as explained by Sabrina in [Appendix A](https://sabrinajewson.org/blog/async-drop#completion-futures) of her post.

Yosh: Async drop is probably superior to this.

tmandry: This post was written back in 2021.

Yosh: The linear types approach wouldn't have been on anyone's radar at this point.

eholk: Even if you have async drop, you have to poll the drop functions from sync code. Async cancellation is potentially useful as an `async Drop` implementation mechanism, even if `async Drop` turns out to be the better surface level semantics.

## Cancellation feedback

zmitchell: It's unclear to me from the document how a caller is supposed to know that the operation was successfully cancelled. Would that just be signaled by the return type of the `async` operation, or is that intended to be stored in the `CancellationToken` somehow?

eholk: I've done some prototyping around similar designs to this one, and ways to get the status of cancellation tend to fall out somewhat naturally in the type system. The exact details depend on the design, but you're almost forced to give feedback or explicitly ignore it.

tmandry: How does that compose? If you're selecting over multilpe I/O features, do all of them need this? It's not obvious in general to me how this should compose.

zmitchell: There's the assertion that you don't need to rewrite code, but I'm not sure that's true, for that reason. Also if you write a third state to the `Poll` enum, everyone has to rewrite everything.

eholk: You change how you desugar await. Then the cancellation bits are invisible. Any manual poll function does need to take this into account. It seems to compose well in that case.

zmitchell: There's a lot of code that assumes that Pending means !Ready.

eholk: Much of that would break in silent ways, which would be unfortunate.

tmandry: Adding a third variant to Poll is probably not feasible.

## Callbacks break the linear control flow of `async`/`await`

zmitchell: Under the [Evaluating the options - CancellationTokens](https://gist.github.com/Matthias247/354941ebcc4d2270d07ff0c6bf066c64#option-d-cancellationtokens) section it proposes allowing the library author to provide a callback that's executed as soon as cancellation is requested. This is a viable solution for immediately cancelling work that's already in progress, but it's a bit of an impedance mismatch for how most `async` code I've seen is written e.g. top-down, linear control flow. It's also harder to reason about.

zmitchell: This is more of a callback style which is what async/await is trying to get away from.

tmandry: That struck me as odd. You could have a future that resolves if your task is canceled and select over that.

eholk: In the prototyping I'm doing, I did end up writing a callback like that, and it is terrible. If we end up writing that in real life, we've clearly failed. The idea is that the cancellation behavior is in the leaf futures. In real-life there hopefully wouldn't be much reason to have this callback. It feels a bit like Defer blocks.

Yosh: This is a bit like creating an anonymous `impl Drop`.

## Cancellation is just one kind of signal

TC: For a project at work, we considered `CancellationTokens`, but we found that in our application that cancellation was just *one* of the many kinds of *signals* that we often needed to send to an ongoing task. So we instead architected to better support sending these (hierarchically-delivered) signals and that also handled cancellation. It's still unclear to me why cancellation would be special enough to deserve its own channel rather than just having a more standardized way to send arbitrary hierarchically-delivered asynchronous signals to asynchronous futures and tasks.

TC: Even for cancellation, we needed to send different *flavors* of cancellation, e.g. whether the task should stop gracefully or immediately.

tmandry: That's an interesting point. You want to get a signal back from the cancellation but it's going to depend what the signal is.

## Cancellation tokens are hard to manage

Yosh:

> The main benefit of CancellationTokens as shown is that they are extremely composable. Most code either does not have to be cancellation-aware (in case the token is implicitely forwarded), or does only have the responsibility to forward the token.

Cancellation tokens somewhat famously don't compose well. In Golang they're passed through to every single function via an explicit `Context` object. And C# does something very similar. Bar the addition of a [context system to Rust](http://tmandry.gitlab.io/blog/posts/2021-12-21-context-capabilities/), you'll almost certainly run into issues when trying to pass cancellation tokens across trait boundaries.

Async Rust's existing cancellation system does not have this issue. The only limitation it has is that we can't call asynchronous code in response to a cancellation - which some form of "async Drop" would ideally resolve.

eholk: Since cancellation tokens would presumably be carried through the context, this is sort of hidden in Rust. Most of the examples in the post show cancellation tokens carried through explicit parameters to the `async fn`s though, so the composability problems are probably real.

## How different are these approaches actually?

eholk: The various ways of expressing cancellation seem largely equivalent to each other.

For example, if the cancellation token is passed through the context, then

fn poll(self: Pin<&mut self>, cx: Context) {
    if cx.cancellation_token().is_cancelled() {
        // do cancellation
    } else {
        // normal poll
    }
}

seems essentially equivalent to:

fn poll(self: Pin<&mut Self>, cx: Context) {
        // normal poll
}

fn poll_cancel(self: Pin<&mut Self>, cx: Context) {
    // do cancellation
}

You can do similar things with `request_cancellation` as well.

tmandry: It was a bit unclear to me on the post whether it was about what the API should be vs what the mechanism or semantics should be.

## You don't need an explicit Cancellation Token type

Yosh: In the [futures-time](https://docs.rs/futures-time/latest/futures_time/) crate we initially shipped a dedicated "CancellationToken" type. But we realized that there is no practical difference between a cancellation token and a zero-sized channel.

This is probably a progression of TC's point above: if you want to use a remote channel rather than just dropping types, you probably want to be able to send different signals - not just the one. And channels support this out of the box.

TC: +1.

tmandry: You could choose what type to attach to the `Context` e.g. with a type parameter on `Future`, or the type provider API, ...

## Let's catch up on the linear types work

TC: Yosh has been publishing a great series on his linear types work. As we talked about at the start of this meeting, the `CancellationToken` work far predated this. Let's be sure to schedule some time to read and talk through Yosh's work so that we're all caught up to the state of the art.

tmandry, others: +1

(The meeting ended here.)