or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Syncing
xxxxxxxxxx
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 there is no mention of "async Drop" as a way of graceful cancellation.
In the absence of true linear types, 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" interpretation of linear types. Rather than the: "types whose destructor is guaranteed to be called" 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. I wrote an additional example on how async-Drop based graceful shutdown could be leveraged for HTTP servers here. This would work even for the "drop is guaranteed to be called" interpretation of linear types, as explained by Sabrina in Appendix A 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 ifasync 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 theCancellationToken
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 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:
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, 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
seems essentially equivalent to:
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 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 onFuture
, 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.)