Hacker News Reader

Comment by rictic | Hacker News Reader

> This means that whenever we decide to throw the switch to multi-threaded WebAssembly, essentially no code needs to change as all of our logic is already written in a concurrent-friendly manner. We simply reap the benefits of a multi-threaded runtime on the Web.

In a multithreaded wasm app, do all threads have equal access to the DOM, or is it more like JS where there is a UI thread which can access all APIs and a bunch of worker threads which can only access a more limited set of APIs?

If the latter, has anyone sought to expose that constraint to the Rust type system? e.g. via a capabilities object that's neither Sync nor Send

View on HN

Last I checked, no WASM has direct DOM access, but instead it all has to go through a bridge to JS.

The question still stands though. Does each individual worker have its own bridge to JS? If so it’s just a constant race condition between them.

Yes, sort of. They can all call into JS, but that JS context is single threaded and serializes access. There can be races depending on what assumptions you make, but those races can't cause memory unsafety of the type usages of Sync and Send are trying to prevent.

How would it serialize? That means potentially interrupting any other JavaScript or WASM code running on the main UI thread and executing other JS code there? That seems kind of against what JavaScript is (100% singlethreaded).

I assume if it’s even possible, it might execute the code only if the main thread is not executing any events - which happens only once per eventloop iteration.

I guess what is happening is that worker can call into JS, but can not access the DOM or anything else living on the main thread. They have to send messages to the other thread, just as JavaScript workers would need to do.

Because it's structured as WASM popping a normal event on the event queue of the normal JS main thread. There's no 'now run JS on the WASM thread but with DOM access'.

> 100% singlethreaded

You can (and should) use Web Workers[1], those run off the UI thread, but also don't have access to the DOM.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

Reply on news.ycombinator.com