-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Threads are Phase 3
https://github.com/WebAssembly/proposals
You can also check out:
https://webassembly.org/roadmap/
And for Go, the proposal project on Github has many interesting conversations from the devs.
And as a reminder to anyone interested in using Go WASM, it’s experimental and does not come with the same compatibility promise as Go itself:
https://github.com/golang/go/wiki/WebAssembly
Threads are Phase 3
https://github.com/WebAssembly/proposals
You can also check out:
https://webassembly.org/roadmap/
And for Go, the proposal project on Github has many interesting conversations from the devs.
And as a reminder to anyone interested in using Go WASM, it’s experimental and does not come with the same compatibility promise as Go itself:
https://github.com/golang/go/wiki/WebAssembly
> You can do attacks that most people haven't been able to do for 20+ years.
This is a bad and roundabout way to say that vulnerabilities in WebAssembly modules may cause a corruption in their linear memory. Which is absolutely true, but those attacks still matter today (not everyone turns ASLR on) and similar defences also apply. In the future multiple memories [1] should make it much easier to guard against remaining issues. WebAssembly is a lucrative target only because it is so widespread, not because it has horrible security (you don't know what the actually horrible security looks like).
[1] https://github.com/WebAssembly/multi-memory/blob/main/propos...
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.
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.
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.
Related posts
-
Bringing Git in the browser via Go and WebAssembly. Upload, create files, folders, branches, commits etc... On the fly in the browser
-
Go: Sentinel errors and errors.Is() slow your code down by 3000%
-
Fast Shadow Stacks for Go
-
Abusing Go's Infrastructure
-
Proposal: Add "SIMD" package to standard library