Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

Travis,

That would be awesome.

I will go over that link and hopefully have starting points for the
discussion.

My day job actually allows me to dedicate time to experimentation (hence
the ClojureScript stuff), so if you have any private branches of IE with
latest DOM experiments, I'd be very happy to explore any new potential or
new efficiency that your ideas may give us! I'm very keen on that, too.

Off list seems to be best here..

Thank you Travis. I really appreciate being able to communicate freely
about ideas.

Marc

On Fri, Feb 13, 2015 at 11:20 AM, Travis Leithead <
travis.leithead@microsoft.com> wrote:

> 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:bzbarsky@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
>
>