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

# WG-async meeting agenda

- Meeting date: 2024-01-29

## Attendance

- People: TC, eholk, Daria Sukhonina, Yosh, Vincenzo, CE

## Meeting roles

- Minutes: TC

## Scheduled meetings

- 2024-02-01: "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!)

## Nominated RFCs, PRs, and issues

### "Tracking Issue for `waker_getters`" rust#96992

**Link:** https://github.com/rust-lang/rust/issues/96992

Yosh: I'm surprised there was no discussion here about the larger idea of doing native vtable support in Rust.

eholk: I've heard discussion about an API to access vtables, but I don't think it's an active priority for anyone. So it's probably doing this now if it's helpful to people.

TC: Here were the recent T-libs-api minutes about this:

> David: I'm unable to rule out the alternatives.
>
> Mara: If it's useful to have a separate type for not-validated pointers, use alternative 1. otherwise alternative 2.
>
> Mara: We can do 1 now, and 2 later.
>
> Josh: +1 for just having public fields
>
> Amanieu: and .as_raw() to read the fields from Waker?
>
> David: yes
>
> David: boats says all three options are fine too.
>
> David: boats: "No strong opinion on those alternatives, I would say do whatever seems most std-like to do. The alternatives mean committing to more, which should be fine, but also having to use these getters in the kind of code that needs this isn't the worst thing in the world. So I don't see a reason to care a lot."
>
> David: I'll cancel the FCP, and propose public fields on RawWaker instead.

Yosh: I mainly care that we don't further close the door on potentially simplifying the `Context -> Waker -> RawWaker -> RawWakerVTable` hierarchy. People are asking about dyn* potentially being a way to simplify this.

eholk: Exposing these fields does close some doors with respect to reorganizing the contents of this type, e.g. changing the nesting of this data. But there seems to already be code in the wild that relies on this layout. Since we didn't promise it, that code is unsound today.

eholk: It seems people have use cases for this, and that's good. There are a number of designs that seem fine.

eholk: I'd probably prefer to use accessors, but exposing the fields seems fine too.

eholk: Probably my preference actually, is moving the accessors to `Waker`. That sounds good too.

Yosh: That would be my preference also.

eholk: It would make it less painful without losing generality.

*Consensus*: While we don't have any specifically strong concerns with any of the proposed options, in our discussions, we did have preference for adding the accessors to `Waker` instead, and we would like to hear the analysis for why it might be better to make these fields public. What's the advantage of that? We weren't able to decipher that from the public discussion.

### "Tracking Issue for `task::Waker::noop`" rust#98286

**Link:** https://github.com/rust-lang/rust/issues/98286

TC: We had discussed this previously and were OK with it, modulo that we wanted it to return `&Waker`, and we had discussed wanting a `Context::noop`.

TC: In working through code using a noop waker, what I've also hit recently is that it would be useful if some of the methods here were const stable. In the spirit of stabilizing primitives first, perhaps we should do that first or concurrently. E.g.:

#![feature(const_waker)]

pub use nop_waker::*;
mod nop_waker {
    use core::{
        future::Future,
        pin::Pin,
        task::{Context, Poll, RawWaker, RawWakerVTable, Waker},
    };
    pub const NOP_RAWWAKER: RawWaker = {
        fn nop(_: *const ()) {}
        const VTAB: RawWakerVTable =
            RawWakerVTable::new(|_| NOP_RAWWAKER, nop, nop, nop);
        RawWaker::new(&() as *const (), &VTAB)
    };
    pub const NOP_WAKER: &Waker =
        &unsafe { Waker::from_raw(NOP_RAWWAKER) };
    // ^^^^ Needs nightly.
    pub const NOP_CONTEXT: Context<'static> =
        Context::from_waker(NOP_WAKER);
    // ^^^^ Needs nightly.
    pub fn poll_once<T, F>(f: &mut F) -> Poll<T>
    where
        F: Future<Output = T> + ?Sized + Unpin,
    {
        let mut cx = NOP_CONTEXT;
        Pin::new(f).as_mut().poll(&mut cx)
    }
}

eholk: What's holding up the const stability here?

yosh: [const waker tracking issue](https://github.com/rust-lang/rust/issues/102012).

eholk: It looks like they were just looking for use cases. What's above seems to be that.

TC: Do we have a meeting consensus in favor of doing this?

Yosh/eholk: +1.

*Consensus*: We view the above as a valid use case for `const_waker`, and we're in favor of stabilizing that feature subject to better understanding the concern that dtolnay raised.

eholk: dtolnay had a concern: https://github.com/rust-lang/rust/issues/102012#issuecomment-1369140411

eholk: Related to this issue:

https://github.com/rust-lang/rust/pull/95985

### "Add LocalWaker support" libs-team#191

**Link:** https://github.com/rust-lang/libs-team/issues/191

Yosh: I have opinions on this one.

struct Context {}
struct Waker(Arc<...>);     // we have this
struct LocalWaker(Rc<...>); // new

impl Context {
    pub fn waker(&self) -> &Waker {}
    pub fn local_waker(&self) -> &LocalWaker {}
}

eholk: I'd like to see a fully worked example of how the full stack would work with `LocalWaker`.

TC: +1.

Yosh: I'm not sure how much it would help alleviate the performance issues folks have. `LocalWaker` still requires every future carry atomics, that smells like a local optimum.

Yosh: Just Karneges wrote [a benchmark](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async/topic/interpreting.20rust-async-bench.20results) showing signifcant overhead for manual `epoll` impls vs futures. Nearly triple the latency, and 15% more cost. At Microsoft we've heard internal teams flag async Rust adding too much overhead compared to implementations in C. There are real questions about whether that means we should introduce a `LocalFuture` / `LocalContext` design too - and what the differences would be.

(The meeting ended here.)

### "Tracking Issue for `Ready::into_inner()`" rust#101196

**Link:** https://github.com/rust-lang/rust/issues/101196

### "Rename `AsyncIterator` back to `Stream`, introduce an AFIT-based `AsyncIterator` trait" rust#119550

**Link:** https://github.com/rust-lang/rust/pull/119550

## Untriaged issues

### "Bad error message using shared borrow of non-sync type across await point" rust#71010

**Link:** https://github.com/rust-lang/rust/issues/71010

### "Poor error message when spawning a future returned by an async fn that takes an owned value as reference" rust#81096

**Link:** https://github.com/rust-lang/rust/issues/81096

### "Function works but non-capturing closure with identical signature fails with strange error" rust#81326

**Link:** https://github.com/rust-lang/rust/issues/81326

### "`implementation of Debug is not general enough` when making async block into `&dyn Future + Send`" rust#87425

**Link:** https://github.com/rust-lang/rust/issues/87425

### "Confusing interaction between associated types, `async fn` and `impl Future`" rust#89657

**Link:** https://github.com/rust-lang/rust/issues/89657

### "Unexpected "the parameter type X may not live long enough" error in asynchronous functions" rust#95719

**Link:** https://github.com/rust-lang/rust/issues/95719

### "Tracking Issue for `waker_getters`" rust#96992

**Link:** https://github.com/rust-lang/rust/issues/96992

### "Implementation of FnOnce is not general enough for `Flatten` iterator of futures outliving an .await point" rust#98380

**Link:** https://github.com/rust-lang/rust/issues/98380

### "async blocks can't forward references" rust#100406

**Link:** https://github.com/rust-lang/rust/issues/100406

### "Mut borrow persists after await" rust#106688

**Link:** https://github.com/rust-lang/rust/issues/106688

### "`async_fn_in_trait` and `return_type_notation` cause awkward awaits" rust#112569

**Link:** https://github.com/rust-lang/rust/issues/112569

### "ICE with "failed to resolve instance for <... as IntoFuture>::into_future: Ok(None)" (regression between 1.73 and 1.74)" rust#119095

**Link:** https://github.com/rust-lang/rust/issues/119095

### "Cycle detected in async fn but not with -> impl Future" rust#119727

**Link:** https://github.com/rust-lang/rust/issues/119727

### "never patterns: `!` argument not detected as diverging on async fn" rust#120240

**Link:** https://github.com/rust-lang/rust/issues/120240

### "Value is incorrectly considered to be borrowed accross await points" rust#120442

**Link:** https://github.com/rust-lang/rust/issues/120442

### "Add LocalWaker support" libs-team#191

**Link:** https://github.com/rust-lang/libs-team/issues/191

## WG RFCs, PRs, and issues nominated for T-lang/T-types

### "`.await` does not perform autoref or autoderef" rust#111546

**Link:** https://github.com/rust-lang/rust/issues/111546

## Pending PRs on the WG-async repo

None.

## `S-waiting-on-team`

### "Rename `AsyncIterator` back to `Stream`, introduce an AFIT-based `AsyncIterator` trait" rust#119550

**Link:** https://github.com/rust-lang/rust/pull/119550

## Proposed FCPs

**Check your boxes!**

### "Tracking Issue for `waker_getters`" rust#96992

**Link:** https://github.com/rust-lang/rust/issues/96992

### "Tracking Issue for `Ready::into_inner()`" rust#101196

**Link:** https://github.com/rust-lang/rust/issues/101196

## Active FCPs

None.

## P-critical issues

None.

## WG-async work project board

https://github.com/orgs/rust-lang/projects/29/views1/d