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 Mechanism for Async Cancellation
2023-11-16: "Reading Club / Open Discussion: Async Cancellation" #323
Link to document: https://theincredibleholk.org/blog/2023/11/14/a-mechanism-for-async-cancellation/
Attendance
Return value of
poll_cancel
TC: This is a nit, but I'd expect
poll_cancel
to return a non-unit value (of a different type thanpoll
). So the signature would be:One often needs to know, e.g., whether cancellation happened cleanly, whether a timeout or abort happened, whether some rollback was not possible, etc.
eholk: There's definitely a use case for that, but I think it's also kind of at odds with using
poll_cancel
as a backing mechanism forasync Drop
, since destructors don't return values currently. (Although maybe they should so we can have fallible destructors too?)TC: Good point. This may be one of those areas where async drop and async cancellation are in fact two different things.
tmandry: Had the same thought. Going in the linear types direction may be another option.
eholk: I really like the "destructors by convention" that you could do if we had a linear type system.
TC: +1.
yosh: -1. I don't think we should go that direction. I think of async as a "portability across domains" mechanism. A kind of portability across effects. So cancellation APIs are a part of that. But the core of it should feel like the same language.
TC: My feeling is that the linear types concepts that we're discussing here would cut across both sync and async.
tmandry: +1. I see these as orthogonal. We could have both. We could have async drop, and we could have the mechanism with explicit destructuring.
yosh: Guaranteed drop and "must use" are maybe two separate things we should distinguish.
tmandry: There is
?Leak
, a type that cannot be leaked, and there is also?Drop
, and we might want them both. We'd have to think about how painful the transition would be.eholk: I think these are different. Linear types would be really valuable for sync code also. They give a lot of power that we currently put into destructors just because we don't have a better way to do it right now. With linear types, destructors become more of a convenience.
Can we really block during unwinding?
tmandry: The post essentially proposes that we
block_on
a future that hasn't finished cancellation during unwinding. Aren't there issues withblock_on
that could lead to deadlocks?And if we could do this during unwinding, why couldn't we also do it during
drop
of the future itself?eholk: I didn't work this idea out fully, but my idea is to basically use
catch_unwind
in theawait
desugaring and then useresume_unwind
afterpoll_cancel
is finished, so we'd be able to suspend during unwinding (which I'll admit sounds absolutely terrifying).tmandry: I've previously thought about how we could do something with poisoning here.
yosh: This could make for a really good use case for
#[no_panic]
functions.yosh: Separately, could we do something more efficient if we knew that the futures were all on the same thread?
eholk: Even if everything is on the same thread you could still get deadlocks.
tmandry: If you think of a tree of futures, each branch represents a thread, so in the analogy with mutexes, each branch can be poisoned.
yosh: Cool, thank you!
Recursive cancellation
TC: In the first post it seemed that you were leaning toward recursive cancellation. What are your thoughts about implementing that under this model?
eholk: I'd like to do an experiment that supports recursive cancellation. It does seem strictly more powerful, but that power might not be useful.
TC: More power of this kind is almost always useful.
tmandry: You could do this by returning a future from cancel, or by signaling it.
eholk: There are some challenges with returning a future, due to types and in particular lifetimes, but it does solve a problem with e.g. cancellation on a vec.
tmandry: This is an area where (hand wave) async Drop would be useful.
eholk: …maybe we could implement IntoCancellableFuture on Vec.
yosh: This is the async-sync-async sandwich but in terms of object lifetimes instead of function calls.
yosh: alternative solution - return a future but mark it as an
AtomicFuture
("cancellation-safe future").Code size
yosh: When I was reasoning through how to implement async Drop, I was worried about the code size - potentially being unbounded. But it seems it's no longer unbounded - just big. Have you measured what the code size overhead is?
yosh: To clarify - I think this will be worth it. I just want to make sure we have a sense of the generated code size.
eholk: I haven't looked into code size at all. I think it is a finite explosion, but finite can still be quite large.