Hacker News new | ask | show | jobs
by rictic 1536 days ago
> 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
1 comments
monocasa 1536 days ago
Last I checked, no WASM has direct DOM access, but instead it all has to go through a bridge to JS.
link
kjsthree 1536 days ago
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.
link
monocasa 1536 days ago
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.
link
Matthias247 1536 days ago
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.

link
monocasa 1536 days ago
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'.
link
fosefx 1536 days ago
> 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...

link