nikomatsakis (Jun 23 2024 at 20:29): nikomatsakis (Jun 23 2024 at 20:29):So I've been reading this blog post by @Dirk Bäumer and working through it. I am exploring a vscode extension and I wanted to define about 4 modules using WIT and then implement some of them in Rust and some in typescript. Unfortunately, I will need async functions, and I gather they are not supported by WIT yet.
I'm finding the relationship of wasm-bindgen, WIT, and wasm-pack fairly confusing. What would be a recommended setup for the above? Can I combine WIT + wasm-bindgen into one project?
Yoshua Wuyts (Jun 24 2024 at 00:02):@nikomatsakis Oh that blog post is fairly out of date. The recent series by Dirk (part 1, part 2) should be more up to date, and I would recommend reading instead.
Yoshua Wuyts (Jun 24 2024 at 00:04):nikomatsakis said:
I'm finding the relationship of wasm-bindgen, WIT, and wasm-pack fairly confusing. What would be a recommended setup for the above? Can I combine WIT + wasm-bindgen into one project?
wasm-bindgen and wasm-pack are tools which I believe even predate WASI 0.1. The equivalent of these for WASI 0.2 would be wit-bindgen and cargo-component. These are designed for WIT, Wasm Components, and WASI 0.2.
Yoshua Wuyts (Jun 24 2024 at 00:14):nikomatsakis said:
Unfortunately, I will need async functions, and I gather they are not supported by WIT yet.
The answer here is nuanced: async functions are supported by WIT. Just not yet as a first-class construct. Instead WASI APIs currently use an epoll-like system based on a Pollable type which requires a little bit of effort to correctly design for.
Yoshua Wuyts (Jun 24 2024 at 00:15):However, that said - my understanding is that the VS Code extension API currently does not support async functionality.
nikomatsakis (Jun 24 2024 at 10:19):@Yoshua Wuyts I think I gave the wrong link, I read the more recent ones too
nikomatsakis (Jun 24 2024 at 10:20):My conclusion after doing a bit more digging was that I should just use sync functions in WIT
nikomatsakis (Jun 24 2024 at 10:20):and setup "completion callbacks"
nikomatsakis (Jun 24 2024 at 10:20):perhaps writing a future on the Rust side if I want to model it
nikomatsakis (Jun 24 2024 at 10:20):I've read your blog post as well but I'll re-read
nikomatsakis (Jun 24 2024 at 10:21):nikomatsakis said:
My conclusion after doing a bit more digging was that I should just use sync functions in WIT
basically it seemed like async in WIT was still a WIP but I wanted to be on the "new hotness" train, and my needs I think are relatively simple
Dirk Bäumer (Jun 24 2024 at 12:15):@nikomatsakis using the technique outlined here you can do the following:
VS Code's component model implementation will take care of the necessary synchronization.
nikomatsakis (Jun 24 2024 at 13:11):I don't follow that last part
nikomatsakis (Jun 24 2024 at 13:11):What is "Async API provided by VS Code" and where can I learn more about it?
Lann Martin (Jun 24 2024 at 13:18):I think they are just referring to the host's call into wasm being async. I am not familiar with vscode's specific implementation but Wasmtime's async feature lets you call (async host) -> (sync guest) -> (async host) where the guest has "no idea" it is in an async stack.
Lann Martin (Jun 24 2024 at 13:27):...though it isn't clear to me that vscode has any way to inject your own host imports into the runtime, so I'm not sure how relevant that really is...
Lann Martin (Jun 24 2024 at 13:31):Anyway you are correct that you have to roll your own async/concurrency today.
Dirk Bäumer (Jun 24 2024 at 18:58):VS Code's API in the extension host is usually async (see for example the FileSytem API). WASM imports can currently only be sync, however by running the WASM code in a worker and using SharedArrayBuffers and Atomics WASM imports can be implemented in an async fashion. We use this to implement the WASI preview1 for VS Code.
nikomatsakis (Jun 27 2024 at 12:50):I tried to setup a callback in wasi but I did something wrong...
#general > how to manage callbacks
not sure what though :)
nikomatsakis (Jul 11 2024 at 20:42):@Dirk Bäumer is the wasm-component-model-async the one that demonstrates how to use webworkers here?
nikomatsakis (Jul 11 2024 at 20:44):or maybe I'm confused
nikomatsakis (Jul 11 2024 at 20:44):I'm trying to remember what I was trying to do even :)
Joel Dice (Jul 11 2024 at 20:50):I don't know what you're trying to do either :), but I know that Jco's preview2-shim demonstrates how to call async JS functions via web workers. Other options are to use asyncify or wait for JSPI to be standardized.
nikomatsakis (Jul 11 2024 at 20:52):I was hoping to build a VSCode extension that consists of a mix of typescript + rust -- but I'm more and more thinking i'll just stick to TypeScript.
nikomatsakis (Jul 11 2024 at 20:52):I don't have a real need to use Rust, I just like it :)
nikomatsakis (Jul 11 2024 at 20:53):The key thing is that I expect the Rust code will need to call into async typescript functions (and vice versa)
nikomatsakis (Jul 11 2024 at 20:53):I was hoping I could use a webworker to hide that or something without too much pain
nikomatsakis (Jul 11 2024 at 20:53):anyway, thanks! asyncify etc looks cool. Count me as an eager future user, I guess, of better async interop...
Joel Dice (Jul 11 2024 at 20:54):webworkers would definitely work, but no guarantees about the "without too much pain" part.
nikomatsakis (Jul 11 2024 at 20:54):it seems like I'd have to write various low-level primtiives to do the blocking etc
nikomatsakis (Jul 11 2024 at 20:54):that...doesn't seem worth it
Joel Dice (Jul 11 2024 at 20:55):Yeah, if you look at the preview2-shim code, it's not simple
nikomatsakis (Jul 11 2024 at 20:56):I guess vscode's worker support is meant to ease this
nikomatsakis (Jul 11 2024 at 20:57):now that I'm re-reading that blog post, I see that the point is that they've done the hard work ...
nikomatsakis (Jul 11 2024 at 20:57):...still. I think i'm going to stick with typescript for now.
nikomatsakis (Jul 11 2024 at 20:57):Thanks again!
Last updated: Nov 22 2024 at 17:03 UTC