On Fri, Jan 27, 2017 at 8:55 AM, Benjamin Smedberg
> Is there something that explains a little more what gains this will buy us
> or how it will be used at the DOM level?
The best link I think is Bill's Quantum DOM blog post:
This post focuses on cooperative multithreading, whereas now we'd like
to get to the point of having preemptive multithreading. From the
engine's perspective much of the reorganization is necessary with
either approach though.
> What will these multiple threads actually be doing, running script from a
> single webpage?
No, we need to preserve run-to-completion semantics for JS, so JS
scripts that can communicate with each other will end up being in the
same zone group and will not be able to execute on different threads.
More precisely, we'll have one zone group for each DocGroup (or maybe
TabGroup, I'm not sure) on the DOM side, per the definitions in this
> How frequent will locking be, and what will locking overhead do to
> performance? Will there ever be shared access to JS object/object graph that
> requires thread locking?
Since threads have exclusive access to the contents of the zone group
they are operating on, there shouldn't be much need for explicit