threads VS motoko-token

Similarly for threads: https://github.com/webassembly/threads

Specifically 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.

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.

There’s a proposal for threads

WebAssembly is having/going to have threads

https://github.com/WebAssembly/threads

It's disappointing to see the WebAssembly/threads proposal is still only in proposal state, despite existing since 2018. It being just a proposal stops languages like golang from actually implementing support for it, despite Chrome supporting it since v70.

Ah, 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...

Another point to add here is that the current wasm specification does not support threads although there is a proposal to add one. So I imagine that till the wasm specification includes it, we will continue to have only single threaded canisters.

G can have some governance system in place (think tokens, proposals, and votes), and token holders can vote on upgrading A. You can take a look at the design/implementation of the governance canister on the NNS for inspiration. Also take a look at this example of creating tokens.