wasi-threads
team
wasi-threads | team | |
---|---|---|
3 | 3 | |
116 | 1,404 | |
1.7% | 0.0% | |
4.2 | 0.0 | |
4 months ago | over 4 years ago | |
WebAssembly | ||
- | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
wasi-threads
-
WASI Support in Go
The answer is: it's complicated. Which is most of the time the answer in the WASI world.
For this case it's complicated because some runtime supports https://github.com/WebAssembly/threads which mostly contains things like the spec for atomic but not the actual "threads" specs and then some runtimes (i.e wasmtime) also supports https://github.com/WebAssembly/wasi-threads which is one version of the threads. But a new proposal came into play https://github.com/abrown/thread-spawn so ... it's complicated.
- State of web assembly and multithreading/Performance?
- The Tug-of-War over Server-Side WebAssembly
team
-
The Tug-of-War over Server-Side WebAssembly
Further down that GitHub issue, it mentions the problem has been fixed:
* https://github.com/rust-lang/rust/issues/71871#issuecomment-...
* https://github.com/rust-lang/rust/pull/79998
Weirdly though, there's another issue (opened prior) that's ongoing and seems to indicate things aren't fixed after all:
* https://github.com/rustwasm/team/issues/291
-
Rust mod team resignation
As for all the rust-wasm stuff, the dispute makes little sense. The "opposition" wants her to transfer publishing rights to a Github group actively being sunsetted and portraying it as a power struggle, yet this struggle is taking place in an issue Williams started in an effort to transfer ownership. Based on the last comments, it looks like publishing rights have been distributed to other members so the whole narrative is effectively moot.
-
rust / emscripten / wasm / opengl / sdl2 / porting..
I don't have direct WebAssembly experience (So far, my projects have either required stuff not compatible with WASI or been DOM-centric "must degrade gracefully with JavaScript disabled" stuff) but this thread looks like a good starting point for answering that question.
What are some alternatives?
browser_wasi_shim - A WASI shim for in the browser
TSC - The Node.js Technical Steering Committee
rust - Empowering everyone to build reliable and efficient software.
cloudlibc - CloudABI's standard C library
hangover - Hangover runs simple Win32 applications on arm64 Linux
workers-wasi
noah - Bash on Ubuntu on macOS
bevy - A refreshingly simple data-driven game engine built in Rust
team - Rust teams structure