Hang on a sec before going off to a private or single-vendor thread
because you think I sent you packing on topics that are of interest (as
opposed to "Thread-Safe DOM").
I'm sorry I missed Travis's mail in my Inbox, but I see it now in the
archives. The topics listed at the link he cites *are* interesting to
many folks here, even if public-webapps may not always be the best list:
-----
IRC log: http://www.w3.org/2014/10/29-parallel-irc
See also: Mohammad (Moh) Reza Haghighat's presentation on parallelism in
the 29 October 2014 Anniversary Symposium talks
We covered three main potential areas for parallelism:
1. Find additional isolated areas of the web platform to enable
parallelism. We noted Canvas Contexts that can migrate to workers to
enable parallelism. Initial thoughts around UIWorkers are brewing for
handling scrolling effects. Audio Workers are already being developed
with specific real-time requirements. What additional features can be
made faster by moving them off to workers?
2. "Shared memory" models. This seems to require an investment in the
JavaScript object primitives to enable multiple threaded access to
object dictionaries that offer robust protections around multi-write
scenarios for properties.
3. Isolation boundaries for DOM access. We realized we needed to find an
appropriate place to provide isolation such that DOM accesses could be
"assigned" to a parallelizable JS engine. Based on discussion it sounded
like element sub-trees wouldn't be possible to isolate, but that
documents might be. Iframes of different origins may already be
parallelized in some browsers.
-----
Mozilla people have done work in all three areas, collaborating with
Intel and Google people at least. Ongoing work continues as far as I
know. Again, some of it may be better done in groups other than
public-webapps. I cited roc's blog post about custom view scrolling,
which seems to fall under Travis's (1) above.
Please don't feel rejected about any of these work items.
/be
Marc Fawzi <mailto:marc.fa...@gmail.com>
February 13, 2015 at 12:45 PM
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
Boris Zbarsky <mailto:bzbar...@mit.edu>
February 11, 2015 at 12:33 PM
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
Brendan Eich <mailto:bren...@secure.meer.net>
February 11, 2015 at 12:04 PM
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