Marc, I'd first mention that I am keenly interested in improving the state-of-the-art in DOM (I'm driving the project to update IE's 20-year-old DOM as my day job.) I've also done a lot of thinking about thread-safe DOM designs, and would be happy to chat with you more in depth about some ideas (perhaps off-list if you'd like).
I'd also refer you to a breakout session I held during last TPAC on a similar topic [1]. It had lots of interested folks in the room and I thought we had a really productive and interesting discussion (most of it captured in the IRC notes). [1] https://www.w3.org/wiki/Improving_Parallelism_Page -----Original Message----- From: Boris Zbarsky [mailto:bzbar...@mit.edu] Sent: Wednesday, February 11, 2015 12:34 PM To: public-webapps@w3.org Subject: Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest 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. -Boris
