Stream: wasi

Topic: Composable WASI interfaces


view this post on Zulip Benjamin Brittain (Apr 23 2020 at 20:06):

as a followup to the W3C WASI sync today, I posted an issue to begin discussing one of the issues Lee and I mentioned

https://github.com/WebAssembly/WASI/issues/262

I'd like WASI function calls to be routed to an instance based on the origin of the handle. This likely requires some dynamic routing capabilities in the wasm runtime. As things currently work,...

view this post on Zulip Benjamin Brittain (Apr 23 2020 at 20:07):

really excited to see what conversation comes of this

view this post on Zulip Till Schneidereit (Apr 23 2020 at 22:01):

I think a lot of this will be addressed by the linking proposal that @Luke Wagner is working on

view this post on Zulip Benjamin Brittain (Apr 23 2020 at 22:04):

Maybe that's grown in scope? I don't think it did when we chatted

view this post on Zulip Benjamin Brittain (Apr 23 2020 at 22:05):

is there a tl;dr on that?

view this post on Zulip Till Schneidereit (Apr 23 2020 at 22:23):

Luke mentioned in the WASI call that he's currently working on an explainer, which I hope should answer this

view this post on Zulip Till Schneidereit (Apr 23 2020 at 22:23):

I'm not sure it will address all of what you mention in the issue, but I do think it should be a good part of a solution

view this post on Zulip Luke Wagner (Apr 23 2020 at 23:25):

Yes, I think there are a couple of separable pieces here to make the end-to-end use cases Benjamin is talking about work. @Dan Gohman also has a doc on a "proxy" feature in wasmtime that i think addresses a different facet of this problem. Lastly, there are some issues the have to do with apps which have multiple stores where stores can independently die with the other stores living on.

view this post on Zulip Lee Campbell (Apr 24 2020 at 00:19):

One other thing to get on the radar is how host/native modules are handled. We've played around with decoupling this from the engine so the host side code doesn't have to live in the codebases of wasmtime, v8 etc... We recently were experimenting with an example of a framebuffer api. On Linux we had a host module where this was implemented with SDL, loaded a .so and could be used by v8, wasmtime and our interpreter without modification. Then when we moved it to windows, we implemented the same API as dll. I thought it was quite nice that to add and use that new API, across different platforms and 3 engines required no changes to the engines themselves.

view this post on Zulip Lee Campbell (Apr 24 2020 at 00:31):

doom.mp4

view this post on Zulip Lee Campbell (Apr 24 2020 at 00:37):

In that little video thats doom running in wasmtime, but using a handle to a framebuffer api to draw to the screen. The backend of that is implemented in a host side lib and calls to it are dynamically routed based on the handle. So no changes required to the engine, and no changes required to the wasm binary when changing the display backend. Would be keen to discuss at some point how folks think about handling this host side code.


Last updated: Oct 23 2024 at 20:03 UTC