W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

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

From: Brendan Eich <brendan@secure.meer.net>
Date: Wed, 11 Feb 2015 12:04:05 -0800
Message-ID: <54DBB5B5.9080700@secure.meer.net>
To: Marc Fawzi <marc.fawzi@gmail.com>
CC: Jonas Sicking <jonas@sicking.cc>, Michaela Merz <michaela.merz@hermetos.com>, Florian Bösch <pyalot@gmail.com>, Glenn Adams <glenn@skynav.com>, Ashley Gullen <ashley@scirra.com>, George Calvert <george.calvert@loudthink.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Marc Fawzi wrote:
> <<
> even if the DOM must remain a single-threaded and truly 
> lock/barrier/fence-free data structure, what you are reaching for is 
> doable now, with some help from standards bodies. ***But not by vague 
> blather***
> >>

Sorry, I was too grumpy -- my apologies.

I don't see much ground for progress in this whole thread or the 
sub-thread you started.

If we're talking about sync XHR, I gave my informed opinion that 
deprecating it is empty talk if actually obsoleting by whichever browser 
takes the first hit inevitably leads to market share loss or (before 
that) developers screaming enough to get the CEO's attention. We will 
simply waste a lot of time and energy (we already are) arguing and 
hollering for and against deprecation, without any definite hope of 
obsolescence.

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).

Doing "over the top" JS libraries/toolchains such as React is excellent, 
I support it. But it does not share mutable or immutable state across 
threads. JS is still single-threaded, event loop concurrency with 
mutable state, in its execution model. This execution model was born and 
co-evolved with the DOM 20 years ago (I'm to blame). It can't be changed 
backward-compatibly and no one will break the Web.

We should add lighter-weight workers and immutable data structures and 
other such things, and these are on the "Harmony" agenda with the JS 
standards body. We might even find race-confined ways to run asm.js code 
on multiple workers with shared memory in an ArrayBuffer -- that's an 
area of active research. But none of these things is anything near to 
what you described in the forked subject line: "Thread-Safe DOM".

I'll leave it at this.I invite others from Mozilla, Google, Apple, and 
MS to speak up if they disagree.

/be
Received on Wednesday, 11 February 2015 20:04:39 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC