Date: July 20, 2023

Link to document: https://blog.yoshuawuyts.com/tree-structured-concurrency/

Leave questions, observations, discussion topics below.

---

## async drop

tmandry: Given that cancellation is immediate in our futures model today (i.e. there is no async drop), and given some reasonable assumptions about our executor and the fact that our other async code doesn't block, we can reason that blocking on cancellation will always be bounded to a few synchronization ops. Is that good enough?

yosh: blocking inside of an async drop may lead to deadlocks if the system doesn't have enough parallelism which is a hard problem. But it may also has performance implications. Unlike errors or panics, cancellation doesn't necessarily live off the happy-path of execution.

tmandry: I agree there's a risk but I think some of these problems are solvable.

yosh: There are also other reasons async drop is interesting.

## Tokio add task::scope / structured concurrency

https://github.com/tokio-rs/tokio/issues/2596#issuecomment-663349217
https://github.com/tokio-rs/tokio/issues/1879
https://github.com/tokio-rs/tokio/pull/2153
https://github.com/tokio-rs/tokio/pull/2576
https://github.com/tokio-rs/tokio/issues/1830
https://github.com/tokio-rs/tokio/pull/2474

TC: Tokio decided that structured concurrency wasn't viable with current Rust, thoughts?

yosh: Definitely agree there are issues with doing this in current Rust

tmandry: I think they wanted borrowing from parent tasks, which is not possible _with_ structured concurrency in current Rust. I covered this issue in detail in https://tmandry.gitlab.io/blog/posts/2023-03-01-scoped-tasks/

yosh: We're looking at lints to detect some patterns in our internal codebases to catch concurrency issues

---

tmandry: I would like if we can iterate on some APIs that we recommend, because the current ones feel inadequate.

yosh: We should focus on language features, we aren't able to express the APIs we want. We need async Drop. Mistake to stabilize APIs before language features; ideally do both together.

tmandry: I agree, but experimenting now seems like a positive direction. Wnat to push back on the idea that we definitely need async Drop. Largely orthogonal, use async drop to wait on cancelled tasks if you have it, but immediate cancellation with runtime integration can work out well too. Patterns can help.

yosh: I would love to see that proven! It'd be great not to have to do async Drop.

TC: Tokio has structured concurrency RFC. It'd be great to go back to them and say the language is already good enough.

yosh: no way to ever guarantee structure from the language.

TC: In other words, the language can't provide something like `Sync` or `Send` to solve this?

yosh: not quite. We can provide APIs that are structured by default, but motivated users can break that system if they want by building their own abstractions, executors, etc. It's a general purpose programming language.

tmandry: Rust isn't purely functional, which limits what you can prove.

yosh: speaking of which, https://blog.yoshuawuyts.com/totality/

TC: are people implementing this?

tmandry, yosh: some interest in compiler implementation, not a lot of language.

yosh: eholk and I have been talking about async Drop a lot lately. "How do you cancel a cancellation" is one of the hardest open questions.

eholk: I'm good with cancelling a cancellation means you just stop cancelling the future and run synchronous destructors instead, but haven't thought through the implications.

TC: We should find a grad student!

---

## Topic

name: prompt

---

## Topic

name: prompt

---