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

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.fawzi@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:bzbarsky@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:brendan@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
>

Received on Sunday, 15 February 2015 00:01:52 UTC