---
title: WG-async planning meeting 2024-02-01
tags: ["WG-async", "planning-meeting", "minutes"]
date: 2024-02-01
discussion: https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async/topic/Planning.20meeting.202024-02-01
url: https://hackmd.io/y_KY5pB0Rqq3VNVBe2xG0A
---

# WG-async meeting agenda

- Meeting date: 2024-02-01

## Attendance

- People: TC, tmandry, eholk, CE, Adam Leventhal, Daria Sukhonina

## Meeting roles

- Minutes:

## Scheduled meetings

- 2024-02-08: "Discuss `async Drop`" [#330](https://github.com/rust-lang/wg-async/issues/330)

Update these [here](https://github.com/orgs/rust-lang/projects/40/views/1).

## Proposed meetings

None.

Update these [here](https://github.com/orgs/rust-lang/projects/40/views/1).

## Announcements or custom items

(Meeting attendees, feel free to add items here!)

## Dates

- 8th:
- `async` Drop.
- 15th:
- `impl Future for std::thread::JoinHandle`
- Context reactor hook.
- Built-in executor.
- TODO: Check with Justin.
- 22nd:
- `AsyncIterator` prototype.
- 29th:
- Async portability.

## Potential topics

- Finalize roadmap (all).
- Maybe discuss tmandry's recent post.
- May have bearing on design principles.
- Probably needs a draft for us all to first discuss async.
- AsyncIterator prototype (TC).
- Async portability (eholk).
- I/O traits.
- Traits for interacting with the executor.
- Reactor abstraction layer.
- `impl Future for std::thread::JoinHandle`.
- Design principles.

## March ideas

- Design principles.
- Probably needs a doc ahead of time.
- WASI Preview 3 async.
- The Preview 3 has a lot of async bits. It'd be interesting to talk with Yosh about this.
- RTN
- `async` Drop overflow.
- Continuing on Yosh's work.
- Daria's blog post.
- Linearity

## Scoped task handles

Daria: I've implemented scoped task handles:

https://zetanumbers.github.io/leak-playground/leak_playground_tokio/task/index.html

## Do we need unwinding?

It'd be easier from a language side if we didn't have it.

CE/TC: But server code needs it to prevent a single request from crashing the entire process.

TC: That really is the singular use case. It's interesting to think about whether we could come up with other solutions to that, then maybe we could get rid of unwinding.

TC: Without unwinding, servers instead may have to be written, e.g., in the pattern of lunatic:

https://github.com/lunatic-solutions/lunatic

It uses WASM to isolate each request.

eholk: We could do instead: `panic = loop`.

Rather than unwinding, we could just leak.

TC: We could take a step toward Erlang. If we provided an abstration where people could express to the language how they were moving shared state around -- they were not using the full general power of shared memory between threads -- that we could guarantee that a crashed thread would be cleaned up without having to support the full power of unwinding.

tmandry: Agreed something like that could work.

eholk: If we had arenas, we could free the entire arena for the request without dropping the objects.

tmandry: The objects couldn't be pinned, or that would violate the pinning contract.

TC: What if we used contexts such that for each request we allocate an arena and then pass via contexts an allocator using that arena to all code that runs for that request? Then we can run drop.

eholk: The trouble is that then passing messages between tasks gets more expensive because you have to copy. Maybe that's OK.

eholk: The "[Singularity]" research project had an "exchange heap" for this.

[Singularity]: https://en.wikipedia.org/wiki/Singularity_%28operating_system%29

Good paper describing exchange heap: https://www.microsoft.com/en-us/research/wp-content/uploads/2006/04/singsharp.pdf

tmandry: There was work on "nurseries" that may apply here.

https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/

eholk: If we could make scoped tasks more powerful, this may follow from that.

tmandry: TC bringing in contexts is really interesting to me. We might be able to track things that way.

(The meeting ended here.)