wasi-threads
memory-control
| wasi-threads | memory-control | |
|---|---|---|
| 3 | 5 | |
| 116 | 19 | |
| 1.7% | - | |
| 4.2 | 0.0 | |
| 4 months ago | over 1 year ago | |
| WebAssembly | WebAssembly | |
| - | GNU General Public License v3.0 or later |
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
memory-control
-
Extism Makes WebAssembly Easy
Indeed, webassembly is moving extremely slowly. I started a project years ago expecting https://github.com/WebAssembly/memory-control/blob/main/prop... and https://github.com/WebAssembly/memory64 to be fixed at some point. Neither are yet, and the project still suffers from it to this day.
I think wasm is still great without these fixes, but I have lost confidence in the idea that wasm will reach its full potential any time soon.
-
The Tug-of-War over Server-Side WebAssembly
Additionally, googlers are championing memory control https://github.com/WebAssembly/memory-control/blob/main/prop..., which provides memory protection.
-
How do Rust WebAssembly apps free unused memory?
But researching it a bit I found this issue, so it clearly seems to be a problem for a bunch of people out there. And apparently both V8 and Spidermonkey have already addressed this quite recently, see this issue.
-
WebAssembly and C++
FWIW there is a proposal in the works to add page-based protection, which will allow unmapping the 0 page, restoring the trap-on-null-deref behavior that is important for many languages with safety checks.
https://github.com/WebAssembly/memory-control
What are some alternatives?
browser_wasi_shim - A WASI shim for in the browser
multi-memory - Multiple per-module memories for Wasm
rust - Empowering everyone to build reliable and efficient software.
asm-dom - A minimal WebAssembly virtual DOM to build C++ SPA (Single page applications)
team - A point of coordination for all things Rust and WebAssembly
sycamore - A library for creating reactive web apps in Rust and WebAssembly
cloudlibc - CloudABI's standard C library
wajic - WebAssembly JavaScript Interface Creator
hangover - Hangover runs simple Win32 applications on arm64 Linux
interface-types
workers-wasi
gc - Branch of the spec repo scoped to discussion of GC integration in WebAssembly