8000 Concurrency support for WebAssembly · Issue #16 · VirtusLab/vss · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Concurrency support for WebAssembly #16

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
tgodzik opened this issue Jan 21, 2025 · 6 comments
Open

Concurrency support for WebAssembly #16

tgodzik opened this issue Jan 21, 2025 · 6 comments

Comments

@tgodzik
Copy link
Member
tgodzik commented Jan 21, 2025

Allow or usage of an API similar to java.lang.Thread, make sure concurrency primitives are available and investigate potential fibers support.

@tgodzik tgodzik added this to the [Task 3] WebAssembly support milestone Jan 21, 2025
@tanishiking
Copy link
tanishiking commented Jan 23, 2025

The stability of the Wasm specifications (threads, stack-switching, and wasi-threads) and the implementation of VMs seem to be blockers for implementing threads and fibers. (It’s also unclear when these specifications and implementations will be finalized).

The situation differs between JS environments and standalone Wasm environments.

  • In JS environments, we can use WebWorkers , and communicate with threads using wasm threads proposal, but I don't think it works very well with WasmGC. So I don't think it doesn't work for us.

  • In standalone Wasm environments, the threads proposal that relies on Web Workers does not exist. Instead, the wasi-threads proposal has been developed. I haven’t explored this in depth yet, but since wasi-threads is still a Phase 1 proposal, it might not be stable yet (Note that WASI proposals and Wasm proposals are separate things https://github.com/WebAssembly/WASI/blob/main/Proposals.md )

  • For green threads, the stack-switching proposal is required. However, this proposal is still in its very early stages (it only recently advanced to Phase 2), and no VM works stably.

@tgodzik
Copy link
Member Author
tgodzik commented May 28, 2025

We should use Gear on JS and test it out this way.

@tanishiking
Copy link

lampepfl/gears#127

@tanishiking
Copy link

From Scala.js 1.19.0, it supports JSPI (kind of on-shot delimcc on JS+Wasm) and Gears supports Scala.js based on it lampepfl/gears#127

Would it be sufficient to create a demo application for Gears (perhaps a CLI application or something) and compile it to Wasm on JS?

@tanishiking
Copy link

Also, I can write a short report about why concurrency doesn't work on Wasm

@tgodzik
Copy link
Member Author
tgodzik commented May 28, 2025

Would it be sufficient to create a demo application for Gears (perhaps a CLI application or something) and compile it to Wasm on JS?

Yeah, that would be totally fine and in scope of the task.

Also, I can write a short report about why concurrency doesn't work on Wasm

That would be useful and also we could add about the proposals that could get implemented in the future

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants
0