On 2/11/15 3:04 PM, Brendan Eich wrote:
If you want multi-threaded DOM access, then again based on all that I
know about the three open source browser engines in the field, I do not
see any implementor taking the huge bug-risk and opportunity-cost and
(mainly) performance-regression hit of adding barriers and other
synchronization devices all over their DOM code. Only the Servo project,
which is all about safety with maximal hardware parallelism, might get
to the promised land you seek (even that's not clear yet).

A good start is defining terms. What do we mean by "multi-threaded DOM access"?

If we mean "concurrent access to the same DOM objects from both a window and a worker, or multiple workers", then I think that's a no-go in Servo as well, and not worth trying to design for: it would introduce a lot of spec and implementation complexity that I don't think is warranted by the use cases I've seen.

If we mean the much more modest "have a DOM implementation available in workers" then that might be viable. Even _that_ is pretty hard to do in Gecko, at least, because there is various global state (caches of various sorts) that the DOM uses that would need to either move into TLS or become threadsafe in some form or something... Again, various specs (mostly DOM and HTML) would need to be gone over very carefully to make sure they're not making assumptions about the availability of such global shared state.

We should add lighter-weight workers and immutable data structures

I should note that even some things that could be immutable might involved a shared cache in current implementations (e.g. to speed up sequential indexed access into a child list implemented as a linked list)... Obviously that sort of thing can be changed, but your bigger point that there is a lot of risk to doing that in existing implementations remains.


Reply via email to