Stream: rust-toolchain

Topic: invoking async javascript functions


view this post on Zulip 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?

Running WebAssemblies in VS Code for the Web.

view this post on Zulip 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.

Using WebAssembly for Extension Development.
Use WebAssembly in VS Code extensions to run in a separate worker, or write a language server with a language that compiles to WebAssembly.

view this post on Zulip 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.

A language binding generator for WebAssembly interface types - bytecodealliance/wit-bindgen
A Cargo subcommand for creating WebAssembly components based on the component model proposal. - bytecodealliance/cargo-component

view this post on Zulip 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.

view this post on Zulip 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.

view this post on Zulip nikomatsakis (Jun 24 2024 at 10:19):

@Yoshua Wuyts I think I gave the wrong link, I read the more recent ones too

view this post on Zulip 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

view this post on Zulip nikomatsakis (Jun 24 2024 at 10:20):

and setup "completion callbacks"

view this post on Zulip nikomatsakis (Jun 24 2024 at 10:20):

perhaps writing a future on the Rust side if I want to model it

view this post on Zulip nikomatsakis (Jun 24 2024 at 10:20):

I've read your blog post as well but I'll re-read

view this post on Zulip 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

view this post on Zulip 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.

view this post on Zulip nikomatsakis (Jun 24 2024 at 13:11):

I don't follow that last part

view this post on Zulip nikomatsakis (Jun 24 2024 at 13:11):

What is "Async API provided by VS Code" and where can I learn more about it?

view this post on Zulip 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.

view this post on Zulip 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...

view this post on Zulip Lann Martin (Jun 24 2024 at 13:31):

Anyway you are correct that you have to roll your own async/concurrency today.

view this post on Zulip 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.

view this post on Zulip 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 :)

view this post on Zulip 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?

view this post on Zulip nikomatsakis (Jul 11 2024 at 20:44):

or maybe I'm confused

view this post on Zulip nikomatsakis (Jul 11 2024 at 20:44):

I'm trying to remember what I was trying to do even :)

view this post on Zulip 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.

JavaScript tooling for working with WebAssembly Components - bytecodealliance/jco

view this post on Zulip 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.

view this post on Zulip nikomatsakis (Jul 11 2024 at 20:52):

I don't have a real need to use Rust, I just like it :)

view this post on Zulip 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)

view this post on Zulip nikomatsakis (Jul 11 2024 at 20:53):

I was hoping I could use a webworker to hide that or something without too much pain

view this post on Zulip 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...

view this post on Zulip Joel Dice (Jul 11 2024 at 20:54):

webworkers would definitely work, but no guarantees about the "without too much pain" part.

view this post on Zulip nikomatsakis (Jul 11 2024 at 20:54):

it seems like I'd have to write various low-level primtiives to do the blocking etc

view this post on Zulip nikomatsakis (Jul 11 2024 at 20:54):

that...doesn't seem worth it

view this post on Zulip Joel Dice (Jul 11 2024 at 20:55):

Yeah, if you look at the preview2-shim code, it's not simple

view this post on Zulip nikomatsakis (Jul 11 2024 at 20:56):

I guess vscode's worker support is meant to ease this

Use WebAssembly in VS Code extensions to run in a separate worker, or write a language server with a language that compiles to WebAssembly.

view this post on Zulip 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 ...

view this post on Zulip nikomatsakis (Jul 11 2024 at 20:57):

...still. I think i'm going to stick with typescript for now.

view this post on Zulip nikomatsakis (Jul 11 2024 at 20:57):

Thanks again!


Last updated: Dec 23 2024 at 13:07 UTC