- From: Brendan Eich <brendan@secure.meer.net>
- Date: Wed, 11 Feb 2015 12:04:05 -0800
- 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