Hacker News Reader

Comment by Animats | Hacker News Reader

Rust targets WebAssembly, which apparently works well because Rust is not garbage-collected.

When will WebAssembly get real threads, not just shared memory between processes? I've seen articles from years ago talking about it as a future feature. Current status?

View on HN

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

Useful 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?

Never because real threads can be used to break out of the sandbox using spectre.

SharedArrayBuffer had been disabled for exactly that reason but has been enabled again for cross-origin isolated pages (https://developer.chrome.com/blog/enabling-shared-array-buff...) - which in turn allows to have 'proper' pthreads in Emscripten: https://emscripten.org/docs/porting/pthreads.html

Can what now? I was under the impression spectre gave you access to data, not arbitrary code execution.

Also, I imagine that web assembly is a bytecode format and that should be _less_ susceptible to spectre.

Can you expand? This seems wrong to me.

Edit: read some papers, I'll be damned, it can. I don't understand how tho'. Would love to try playing with a POC that does that.

See https://blog.mozilla.org/security/2018/01/03/mitigations-lan...

What is a "real" thread? A POSIX thread?

The entire notion of processes and threads is a bit weird inside of a WASM module. Arguably a WASM module shouldn't care about them at all - the host runtime should be managing parallelism.

The host runtime might provide the ability to spawn threads, but WASM would presumably still need to establish a memory model. I don't know if it has one, or not.

(Or, I suppose it can just completely isolate the memory between threads, and say nothing is shared. But I don't think that's what people would want?)

I'm confused. certainly as an application developer in most languages today I have to be aware of and manage any execution concurrency

Half of the article is entirely about GC.

> Support for built-in GC set to ship in Q4 2023

Parent is asking about threads not GC.

Add to that GC implementation is different for each language, so having generic garbage collector might not be desirable. Consider Erlang which supports millions of processes per node:

> Each Erlang process has its own stack and heap which are allocated in the same memory block and grow towards each other. When the stack and the heap meet, the garbage collector is triggered and memory is reclaimed. If not enough memory was reclaimed, the heap will grow.

That said, there is a WebAssembly compiler for Erlang:

https://github.com/GetFirefly/firefly

What do you need for "real" threads functionality, beside shared memory? Shared mutexes? Fair; Rust somehow implements them, but I don't know how. Shared file descriptors, sockets, etc? They don't seem to exist, and if they did, I think sending (moving) them between threads in a message would do the trick.

What else am I missing?

More compute power, for games. I need about a half dozen CPUs running flat out.

Could one just treat WebAssembly as virtual bare metal, implement a multithreaded OS in WebAssembly and then spawn threads inside that?

That's basically how the Go WASM runtime works[1], except when calling outside the WASM virtual machine (e.g. invoking a JavaScript function) the entire Go runtime must block.

[1] The Go compiler inserts yield calls (preemption opportunities) at various points in the emitted code, such as at function invocations and within loops.

Technically you could, but they'd all be run on the same CPU core.

You could spawn a Web Workers for each core, in theory, although some browsers will lie about the number of cores.

> Technically you could, but they'd all be run on the same CPU core.

Right. The goal for games is to get more CPUs working on the problem.

What's the difference between real threads and shared memory between processes? I don't really follow. Memory object is all you have in webassembly for your process. If it's shared between multiple workers, you basically get threads.

Among other problems, each worker has to instantiate all the host javascript objects and instantiate its own copy of the wasm module, which has its own unique copy of the imports and the function pointer table. It's definitely way less elegant than real threads and potentially creates performance and stability issues.

You also now have fun thread affinity problems, like if you call setTimeout your timer IDs now have thread affinity, which is nonsense.

what do you see as the important difference between real threads and interprocess shared memory?

When time skews and you get sent back a decade or two.

Reply on news.ycombinator.com