owned this note   changed a year ago  
Published Linked with GitHub

Background on context reactor hook

https://jblog.andbit.net/2022/12/28/context-reactor-hook/

https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async/topic/Context.20reactor.20hook

https://github.com/jkarneges/waker-waiter/issues/1

Discussion

Attendance

  • People: TC, tmandry, yosh, Daria, Vincenzo, Justin Karneges

Meeting roles

  • Minutes, driver: TC

Are we right to specialize this to futures?

yosh: This proposes passing a Reactor argument via the task::Context type down into futures internals. This makes two assumptions:

  1. A reactor argument is inherently accessed from the poll state machine of future internals
  2. This is something unique enough to futures, and so using a dedicated mechanism for futures is justfied

Yosh: To the first point, I just finished writing a counter-example in the wasi-async-runtime crate. Here the Reactor::wait_for method creates a concrete future which must be .awaited, rather than needing to manage manual callbacks in poll state machines.

TC: Isn't this a "turtles all the way down" sort of thing? I.e., the problem here is that something in the synchronous world needs to block to then trigger the wake up of one or more futures. How would creating yet another future that needs to be awoken help here?

Yosh: What I'm trying to get at is that "obtain the reactor from the Context param" is too low-level, at least with our current tools. In the WASI world we're not really interested in obtaining the reactor at the level of poll state machines; we're interested in obtaining it at the level of "async/.await". Granted, there may be opportunities to use it with manual futures - but that's a matter of passing the reactor into the manual futures.

TC: It's not clear to me whether, in that WASI code, you're trying to solve this same problem or whether it's a different problem. Maybe it's correct for there to be another layer for solving the problem the WASI code wants to solve here that is distinct from the problem that Justin is trying to solve.

Yosh: It's definitely the same problem - but WASI has a slightly different polling model than Linux or MacOS have. This means the best way to pass the reactor down is not as an argument via the poll state machines, but as arguments to async functions. The differences are not in the intent, they're in the actual polling model.

TC: What's special about WASI here, as compared to Linux, that calls for the differences in approach you mention?

Yosh: The WASI polling model is entirely single-threaded, which is one difference. The second one is that it uses unique interest tokens on a per-operation basis, which differs from the epoll model which registers interest on a per-resource basis. This means the interest is registered in the function, rather than on the resource - which I think is what underlies the difference in how we end up exposing it. Here is a concrete example:

use wasi::http::outgoing_handler::{handle, OutgoingRequest};
use wasi::http::types::{Fields, Method, Scheme};
use wasi::io::poll;

fn main() {
    // Construct an HTTP request
    let fields = Fields::new();
    let req = OutgoingRequest::new(fields);
    req.set_method(&Method::Get).unwrap();
    req.set_scheme(Some(&Scheme::Https)).unwrap();
    req.set_path_with_query(Some("/")).unwrap();
    req.set_authority(Some("example.com")).unwrap();

    // Send the request and wait for it to complete
    let res = handle(req, None).unwrap();  // 1. We're ready to send the request over the network
    let pollable = res.subscribe();        // 2. We obtain the `Pollable` from the response future
    poll::poll(&[&pollable]);              // 3. Block until we're ready to look at the response

    // We're now ready to try and access the response headers. If
    // the request was unsuccessful we might still get an error here,
    // but we won't get an error that we tried to read data before the
    // operation was completed.
    let res = res.get().unwrap().unwrap().unwrap();
    for (name, _) in res.headers().entries() {
        println!("header: {name}");
    }
}

TC: Are you proposing that doing this in the Context is not expressive enough for the WASI code or that it would be awkward in the implementation.

Yosh: It leans more toward the awkward.

TC: Are you writing up a counterproposal here?

Yosh: I'm partial to the general context mechanism, as in tmandry's post. There are a number of use cases here beyond async Rust. If we could solve this problem generally, that'd be better.

tmandry: The leaf future is what needs to interact with this reactor. And that's generally written in the poll style. So I'm not really understanding here.

Yosh: In the WASI case, we can write the leaf futures with async fn.

https://github.com/yoshuawuyts/wasm-http-tools/blob/main/crates/wasi-http-client/src/lib.rs#L37-L45

eholk: If we think of this as a monad, the context is the thing that's being threaded through. We want the reactor to be threaded through in this same way. The plumbing is already there. There may be other things we'd want to plumb through in this same way also, and that may help with avoiding use of TLS.

Yosh: Here are two examples for discussion:

Justin: I feel like this would work in the context reactor model.

Continuing the second point from above

Yosh: To the second point, Tyler wrote a post on a generalized mechanism for this in late 2022: context and capabilities for Rust. Examples of other things we want to pass down "contextually" mentioned by the blog post include loggers, allocators, and executors. Why would we believe that this a unique mechanism specifically for contexts would be justified - and why wouldn't we pursue the more general mechanism if we know that shares many of the issues?

TC: If we had had a general context mechanism, perhaps we would have used that in the first place rather than adding a Context argument to Future::poll.

Yosh: I'm not sure tbh - all futures do need to always pass a Waker of some kind. Contexts seem more suited for things which may not always need to be passed? But maybe I'm wrong, and it would actually have made sense to pass it via a context.

eholk: It looks like the wasi-runtime still bottoms out in a poll_fn: https://github.com/yoshuawuyts/wasm-http-tools/blob/main/crates/wasi-async-runtime/src/reactor.rs#L70

So it seems like maybe this is structured so there's essentially just one leaf future and everything else is built around that.

Yosh: You're not wrong.

QueryInterface

eholk: In the Windows/COM world there's QueryInterface, which gives a way to let objects dynamically support an unbounded set of interfaces. I wonder if it'd make sense to apply something like that here to make things more easily extensible? It might look like:

fn poll(self: Pin<&mut Self>, cx: Context) {
    let waiter = cx.get_service::<Waiter>().unwrap();
}

Unfortunately, this would almost certainly not be zero cost, so it may be unacceptable overhead for low level future mechanics.

tmandry: …there is a proposal for this, "Provider".

Justin: I do like this idea. I put this in the Context because we don't have that mechanism.

Justin: The waker_getters mechanism is going to help here.

Nouns

tmandry: There are a lot of nouns in this proposal. Let's map them out?

Justin: I tried to keep these names minimal so they don't imply too much.

Executor is presenting itself as the TopLevelPoller.

Type safety

yosh: This erases the types we're passing around. The types are not equivalent - and we probably want to stabilize shared interfaces. How are we evaluating this? Is type-unsafety ok here? Would we prefer a type-safe interface?

eholk: we might be confusing two things here: dyn traits and option. dyn traits don't give you a runtime failure. We would be introducing new optional types - and that could introduce runtime failures yes. That raises a question about graceful degradation.

Example of how this all works

Justin:

hackish tokio example

(The meeting ended here.)

Select a repo