People in the WebAssembly standards group are recently considering relaxing the limitation that the main thread can't use atomic.wait: https://github.com/WebAssembly/threads/issues/177#issuecomme...
In Theseus: Translating Win32 to WASMWebAssembly
threads
WebAssembly2017–2026
WebAssembly / threads
threads
Threads and Atomics in WebAssembly
24Distinct people
26Mentions
0Explicit recommenders
772GitHub stars
What to know before exploring
What it is
Threads and Atomics in WebAssembly
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- webassembly/proposals · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:56:56 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year26 dated mentions
Observed mentions: 2017-05-15 18:41:17 UTC to 2026-05-27 19:41:44 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Threads Proposal for WebAssembly
This repository is a clone of github.com/WebAssembly/spec/. It is meant for
discussion, prototype specification and implementation of a proposal to threads
support to WebAssembly.
See the overview for a summary of the proposal.
A formatted version of the spec with proposed changes is available here:
webassembly.github.io/threads.
Original README from upstream repository follows...
spec
This repository holds the sources for the WebAssembly draft specification
(to seed a future
WebAssembly Working Group),
a reference implementation, and the official testsuite.
A formatted version of the spec is available here:
webassembly.github.io/spec,
Participation is welcome. Discussions about new features, significant semantic
changes, or any specification change likely to generate substantial discussion
should take place in
the WebAssembly design repository
first, so that this spec repository can remain focused. And please follow the
guidelines for contributing.
citing
For citing WebAssembly in LaTeX, use this bibtex file.
Read the full README on GitHubWhat Hacker News says
26 sourcesThere is a proposal to add threading to WASM itself
https://github.com/WebAssembly/threads/blob/main/proposals/t...
But that’s not going to help when accessing the DOM.
In Show HN: Parallel DOM – Upgrade your DOM to be multithreadedSimilarly for threads: https://github.com/webassembly/threads
In No installation required: how WebAssembly is changing scientific computingSpecifically I submitted this to draw attention to the latest comment in the thread: https://github.com/WebAssembly/threads/issues/177
It's a good deep dive into how a small, but well-intentioned, browser choice nearly a decade ago led to poor outcomes for the WebAssembly ecosystem.
In WebAssembly: Adding atomics waits to the main thread is the right thing to doWebAssembly: Adding atomics waits to the main thread is the right thing to do
5 points · Open discussionThe 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.
In WASI Support in GoUseful info is here:
https://github.com/WebAssembly/threads/blob/main/proposals/t...
Atomics are well covered. The "wait" and "notify" primitives map efficiently to mutexes.
"Blocking on the main thread is not allowed, so we can't call lockMutex."
The main thread is special in WebAssembly land. Is it still the only one that can do graphics?
In A world to win: WebAssembly for the rest of usThere is a WebAssembly proposal called "Threads".
https://github.com/webassembly/threads
"This proposal adds a new shared linear memory type and some new operations for atomic memory access. The responsibility of creating and joining threads is deferred to the embedder."
As for the current status, it is listed on the proposals page: https://github.com/WebAssembly/proposals
The "Threads" proposal is in "Phase 3 - Implementation Phase" which means it's starting to be implemented, but it hasn't reached "Phase 4 - Standardize the Feature" where 2+ browsers implement it. The final stage would be "Phase 5 - The Feature is Standardized. See https://github.com/WebAssembly/meetings/blob/main/process/ph...
In A world to win: WebAssembly for the rest of usThat's incorrect. WASM supports the exact same multi-threaded/shared-memory/atomic-operations model as the JVM: https://github.com/WebAssembly/threads
In Wasmtime 1.0> Were these facilities added to a wasp runtime,
https://github.com/WebAssembly/threads/blob/main/proposals/t...
In Learn Postgres at the Playground – Postgres compiled to WASM running in browserWebAssembly is having/going to have threads
https://github.com/WebAssembly/threads
In LibreOffice running natively in the browser via WebAssemblyAh, I should have clarified that I mean the assembly instructions for atomics, rather than the JavaScript API. I.e. the opcodes listed here: https://github.com/WebAssembly/threads/blob/master/proposals...
In Using WebAssembly threads from C, C++ and RustWasm is not basically assembler, it's (going to be) very high level:
- https://github.com/WebAssembly/reference-types
- https://github.com/webassembly/threads
- https://github.com/WebAssembly/exception-handling
- https://github.com/WebAssembly/function-references
- https://github.com/WebAssembly/gc
Though it is true that the original MVP was very barebone and could be compared to assembler. However, the reference types proposal has been shipped in all major browsers and is considered "finished".
In WebContainers: Run Node.js natively in the browserI explicitly stated I was talking about WASM being used in traditionally native process contexts - like in a serverless/microservices architecture. The first obvious step of someone offering that is to just import libc so existing code can migrate to it.
You seem to be continually focusing exclusively on the current existing extremely limited WASM-in-a-browser usage.
WASM's current limitations aren't intentional, it's because it's not finished & wasn't necessary for the MVP. In fact, it already has some of the things you are claiming it doesn't have - both threads & shared memory are available already in Chrome & Firefox's stable releases ( https://github.com/WebAssembly/threads/blob/master/proposals... & https://webassembly.org/roadmap/ ). Which means it also has accurate timers.
WASM very intentionally allows the host to expose whatever
Read the rest
feature set it wants. That's a very core design element. You can't just ignore that and focus on the ~nothing that the "spec" itself delivers & pretend that's by-design. WASM isn't a standalone runtime and isn't trying to be.
You're talking about some hypothetically fully featured WASM that has all kinds of attack surface it simply doesn't have today. It doesn't even have threads; nor accurate timers, nor shared memory; and those choices aren't by coincidence, they're by design to keep things safe (see e.g. https://github.com/WebAssembly/threads/issues/8).
If indeed webassembly adds features that add attack surface, I sure hope (and fully expect) them to take things like spectre into consideration.
As to SELinux: the issue with securing existing programs is that those use all kinds of existing features; it's quite hard to take away functionality that programs depend on. SELinux simply has a much harder and trickier task than WASM, which never supported almost everything SELinux seeks to control in the first place. It may well be that it's possible to have SE
Read the rest
Linux enforce WASM-or-greater restrictions and that it would then be "safer" due to other features, but that's a pretty hypothetical scenario - what software would even run in those circumstances?
The comparison seems moot to me; apples to oranges. One is trying to KISS and be safe by simply not having complex features; the other is trying to deal with real, existing programs by restricting stuff they could access but don't need. Those are different use cases.
Showing the 15 most recent of 26 sources. Enable JavaScript to search and browse every indexed mention.