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 


-----Original Message-----
From: Boris Zbarsky [] 
Sent: Wednesday, February 11, 2015 12:34 PM
Subject: Re: Thread-Safe DOM // was Re: do not deprecate synchronous 

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 

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