Improving Parallelism Page

<<= Back to Session Grid | Back to Session Ideas

IRC: #parallel

Breakout description

Today's web applications are primarily single-threaded. Web Workers introduced the ability to use concurrency in web applications, but Workers often fail to meet developers expectations due to the relative isolation of the Worker's environment from the main thread of execution. This session is to discuss and explore the idea of improved concurrency for web applications.

Discussion Questions

Is improved concurrency (beyond what exists today) necessary?
What are some of the use cases/gaps with existing concurrency solutions (Workers, ServiceWorkers, SharedWorkers)
Where should more investigation be directed?

Participants

Travis, zcorpan, tobint, mikesmith, hober, Cyril, philcohen, rbyers, tripu, annette_g, ujvari, kinkjim, alex, rniwa, joe (and many more)

Summary

After review of the current browser platform architecture (it's single-threaded-ness) and the other features that enable parallelism like Worker, SharedWorker, ServiceWorker), we delved into the use cases brought by those attending the session: everything from big data processing, to enabling native app performance. We then had an active discussion about potential designs and drawbacks for achieving better parallelism.

Notes from the Breakout

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.

Actions/Followup

Investigate new models for JS objects that can be written safely with multiple threads. ('value' properties??)