[goldenkey]

I'm pretty sure OP knows about postMessage. That wasn't his point.

The only way to pass data is through message passing - but the message passing takes only strings. Just object serialization and deserialization in JS is slow enough to make it infeasable to do large-scale transfer between the two without paying for transmuting the data.

We need immutable object passing for performance. Or locked mutable object passing (like Rust.)

And why not the ability to modify DOM elements with the repaints happening on the main thread?

[woogley]

You're looking for Transferable Objects:

https://developer.mozilla.org/en-US/docs/Web/Guide/Performan...

[chongli]

Still seems like quite a hack. Why can't we just have immutable objects shared by all webworkers?

[goldenkey]

Sweet beavus!

[marcosscriven]

I had exactly this issue when trying to make my OpenSCAD port multithreaded in asm.js - the results of each worker took longer to serialise/deserialise than the time saved by doing them in parallel. Unfortunately couldn't even use transferable objects, as the C++ objects in question were CGAL nef polys, and once copied across would be garbage. It would work though if you have objects you can allocate to a specific buffer (I since discovered called a 'bump allocator')

https://groups.google.com/forum/m/#!searchin/emscripten-disc...

[mistercow]

>And why not the ability to modify DOM elements with the repaints happening on the main thread?

It's not just a matter of repaints. You'd actually have to make the DOM thread safe, which is not trivial.

[goldenkey]

I think locking the DOM might not be too difficult. To have multi-threaded accessors/getters would be insanely tough given the size of the existing code-base. But a single exclusive lock over the DOM could work.

[mistercow]

There are several problem with that. One is that the web worker would block all user input, including scrolling, while you were modifying the DOM. Also, the locking would absolutely have to be manual. Locking before each DOM modification and then unlocking after would be disastrous, since you'd have no guarantees about the DOM's state from one call to the next. And once you introduce manual locking, you're largely defeating all of the safety guaranteed by workers in the first place.

Or think of it this way: If you can lock the DOM reliably and efficiently, then you can write code that shares memory by storing data in the DOM, rather than copying it between workers. That would get you most of what you get from ordinary threads, albeit with only one lock available. This would be such a huge convenience and performance win, that if it were possible, they'd have done it to allow memory sharing without going through the DOM at all. That right there should tell you that allowing DOM access from workers by locking is impractical.