dan - great work on https://github.com/WebAssembly/WASI/blob/7d6a36e4f52c3965b8e8732061e1b9642e2bb276/docs/DesignPrinciples.md
the biggest thing we've discussed that I think is missing is discussion of how WASI IO can become async (reactor model) in order to fit into the web context better
because thats a big motivator for native wasm coroutines
is that something that you think belongs in this doc? or is that a separate discussion, because we're a lot less sure of the details?
I think I'm not ready to say a lot about async here, as the shape of the solution (or solutions?) is not yet fully known
sgtm
Maybe one thing I can say is, that hopefully async will be done in a way that we can adapt any blocking API to use
i think it would be nice to discuss some of our ideas / uncertainty about async at the cg meeting, and whether wasm coroutines are a tractable idea or bound for a V8 Veto
So, right now the focus of WASI design is figuring out the functionality set and how portability and security work
And it'll all hopefully be orthogonal to async once we're ready to mix that in
ive tried to get alon interested in championing coroutines, but all he'll say is that he agrees they're important
fair enough.
Yeah. I think coroutines are currently something Andreas is championing
so shopping around for a google coroutines champion is a non-WASI thing, then.
ah ok. i havent talked to him about them yet.
Yeah, whatever form coroutines take, we'll need to start with a core wasm spec feature
There'
s also Reactor/callback-style async, which is something that Interface Types will help enable
Last updated: Dec 23 2024 at 12:05 UTC