2 ms·
Last I checked, no WASM has direct DOM access, but instead it all has to go through a bridge to JS.
by monocasa 5y ago
Last I checked, no WASM has direct DOM access, but instead it all has to go through a bridge to JS.
- kjsthree 5y agoThe 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.
- monocasa 5y agoYes, 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.
- Matthias247 5y agoHow 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.
- monocasa 5y agoBecause 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'.
- fosefx 5y 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_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...