Web Workers: current architecture and potential future project ideas

[Kinuko Yasuda]

Hello,

As I sometimes got asked about the overview of current Web Worker code, I wrote up a document that summarizes the current architecture, implementation and potential future project ideas for Web Workers in Blink (i.e. dedicated worker, shared worker, service worker and compositor worker and possibly more to come).

Hope this is helpful for people who happen to need to work on/understand the worker code.

https://docs.google.com/document/d/1i3IA3TG00rpQ7MKlpNFYUF6EfLcV01_Cv3IYG_DjF7M/edit#heading=h.7smox3ra3f6n

Any feedback, comments, or suggestions for more potential project ideas are welcome!

Kinuko

[Anne van Kesteren]

On Thu, Nov 5, 2015 at 3:43 PM, Kinuko Yasuda <kin...@chromium.org> wrote:
> Any feedback, comments, or suggestions for more potential project ideas are
> welcome!

Last week at TPAC I found out that neither Apple nor Microsoft have
any intent of shipping shared workers (Apple did ship them for a
while, but reportedly the feature has been removed per iOS 9). Should
Google and Mozilla follow suit?


--
https://annevankesteren.nl/

[Dimitri Glazkov]

Love this doc. The first part of it (until future project) looks like a solid documentation piece that could live as a Markdown doc in the core/workers.

:DG<

[Marijn Kruisselbrink]

Chrome on Android never shipped shared workers either fwiw.

[Kentaro Hara]

Love this doc. The first part of it (until future project) looks like a solid documentation piece that could live as a Markdown doc in the core/workers.

+1. I love to have this kind of documentation (or at least a link to the document) in the code base! Blink architecture needs more documentation.

Thanks for writing a great document.

--

Kentaro Hara, Tokyo, Japan

[Kinuko Yasuda]

On Fri, Nov 6, 2015 at 10:03 AM, Marijn Kruisselbrink <m...@chromium.org> wrote:

On Thu, Nov 5, 2015 at 11:57 PM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Thu, Nov 5, 2015 at 3:43 PM, Kinuko Yasuda <kin...@chromium.org> wrote:
> Any feedback, comments, or suggestions for more potential project ideas are
> welcome!

Last week at TPAC I found out that neither Apple nor Microsoft have
any intent of shipping shared workers (Apple did ship them for a
while, but reportedly the feature has been removed per iOS 9). Should
Google and Mozilla follow suit?

That's sad.  Unshipping shared workers in Chrome is a tough choice, if not impossible, at least for now.  The usage is actually not that high but not low enough to consider deprecation, and we have some important Web sites (like Google docs) that extensibly use shared workers.  We will need a convincing alternative solution that existing customers can migrate to.  Service Worker could be one choice, but the lifetime constraints seem to be one of the hurdles for shared worker users, and service workers aren't implemented in neither Apple nor Microsoft either yet.

Chrome on Android never shipped shared workers either fwiw.

Hmm.  Now that we deprecated dedicated worker process shipping this should be basically just a matter of flag flipping...

[Kinuko Yasuda]

Yep. I plan to make a markdown something similar to this, or maybe a link to the doc, and put in the code base.

Agreed that more documentation in the code base would make us happier.

[Ben Kelly]

On Fri, Nov 6, 2015 at 3:04 AM, Kinuko Yasuda <kin...@chromium.org> wrote:

On Fri, Nov 6, 2015 at 10:03 AM, Marijn Kruisselbrink <m...@chromium.org> wrote:

On Thu, Nov 5, 2015 at 11:57 PM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Thu, Nov 5, 2015 at 3:43 PM, Kinuko Yasuda <kin...@chromium.org> wrote:
> Any feedback, comments, or suggestions for more potential project ideas are
> welcome!

Last week at TPAC I found out that neither Apple nor Microsoft have
any intent of shipping shared workers (Apple did ship them for a
while, but reportedly the feature has been removed per iOS 9). Should
Google and Mozilla follow suit?

That's sad.  Unshipping shared workers in Chrome is a tough choice, if not impossible, at least for now.  The usage is actually not that high but not low enough to consider deprecation, and we have some important Web sites (like Google docs) that extensibly use shared workers.  We will need a convincing alternative solution that existing customers can migrate to.  Service Worker could be one choice, but the lifetime constraints seem to be one of the hurdles for shared worker users, and service workers aren't implemented in neither Apple nor Microsoft either yet.

I think removing SharedWorker would be quite hard for Mozilla at this time as well.  In addition to web compat issues as mentioned above, Firefox OS is planning to use SharedWorkers heavily in the future.  A convincing alternative could perhaps satisfy fxos's needs, but it obviously would depend on the details.

Ben

[Jochen Eisinger]

ServiceWorkers are essentially shared workers.

[Philip Jägenstedt]

On Fri, Nov 6, 2015 at 12:04 AM, Kinuko Yasuda <kin...@chromium.org> wrote:

On Fri, Nov 6, 2015 at 10:03 AM, Marijn Kruisselbrink <m...@chromium.org> wrote:

On Thu, Nov 5, 2015 at 11:57 PM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Thu, Nov 5, 2015 at 3:43 PM, Kinuko Yasuda <kin...@chromium.org> wrote:
> Any feedback, comments, or suggestions for more potential project ideas are
> welcome!

Last week at TPAC I found out that neither Apple nor Microsoft have
any intent of shipping shared workers (Apple did ship them for a
while, but reportedly the feature has been removed per iOS 9). Should
Google and Mozilla follow suit?

That's sad.  Unshipping shared workers in Chrome is a tough choice, if not impossible, at least for now.  The usage is actually not that high but not low enough to consider deprecation, and we have some important Web sites (like Google docs) that extensibly use shared workers.  We will need a convincing alternative solution that existing customers can migrate to.  Service Worker could be one choice, but the lifetime constraints seem to be one of the hurdles for shared worker users, and service workers aren't implemented in neither Apple nor Microsoft either yet.

It looks like SharedWorkerStart is the use counter for this. I wouldn't have guessed that Google docs is <0.06% of page loads, but that is about 1 in 1700, so it might just be right.

Anne, Kinuko, do either of you have any insight into why Apple and Microsoft don't want to support shared workers?

Philip

[Philip Jägenstedt]

I found https://github.com/whatwg/html/issues/315 

[Jonas Sicking]

I definitely think that service workers could fill the need of shared
workers. But they would need some changes in order to meet these
needs.

The use case that we have for FirefoxOS is to have an execution
context which can coordinate things like database access and server
access for multiple running windows. I.e. for many pieces of UI.

With a shared worker that is quite easy to do. Simply calling "new
SharedWorker(url)" gives you access to an execution context which does
that coordination.

Additionally this execution context needs to preload data (from
network and/or indexedDB) which we expect to be used soon or often and
keep it in memory.

Right now a lot of this is much harder to do using service workers.
But it doesn't need to be. For example I don't see a reason to not
enable doing

var sw = new ServiceWorker("url");
sw.postMessage("...");
sw.onmessage = (e) => {...};

and let that work independently of if the SW has been registered yet or not.

Additionally, we need a solution for quickly accessing data. We could
either allow service workers to have greater control of their lifetime
so that they can keep data in memory. Or we need to better heuristics
or explicit control to keep IDB databases in memory.

/ Jonas

> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.

[Kinuko Yasuda]

Hi Jonas,

I agree that service workers and shared workers have overlapping characteristics, but also agree that it is hard (or impossible) for all the existing shared worker users migrate over service worker as is.

(Btw as Phillip mentioned https://github.com/whatwg/html/issues/315 is probably more relevant place to discuss this)

On Sun, Nov 22, 2015 at 3:22 PM, Jonas Sicking <jo...@sicking.cc> wrote:

I definitely think that service workers could fill the need of shared
workers. But they would need some changes in order to meet these
needs.

The use case that we have for FirefoxOS is to have an execution
context which can coordinate things like database access and server
access for multiple running windows. I.e. for many pieces of UI.

One of the most popular use case for Chrome's shared worker is exactly same or similar (I made a comment on https://github.com/whatwg/html/issues/315 too).  There could be multiple tabs opened for one site and each talks to a single backend shared worker that coordinates database access and server access.  The shared worker also serves as an efficient in-memory cache between the app and database/server, which cannot be realized with today's service worker lifetime semantics.

With a shared worker that is quite easy to do. Simply calling "new
SharedWorker(url)" gives you access to an execution context which does
that coordination.

Additionally this execution context needs to preload data (from
network and/or indexedDB) which we expect to be used soon or often and
keep it in memory.

Right now a lot of this is much harder to do using service workers.
But it doesn't need to be. For example I don't see a reason to not
enable doing

var sw = new ServiceWorker("url");
sw.postMessage("...");
sw.onmessage = (e) => {...};

I like the brevity but this usage feels very different from today's service workers.  If we have different usages it feels having different APIs is reasonable... while extending the scope of service worker might be worth discussing too.  For these ideas could we file bugs on SW github if we think these should be in the scope of SW?

https://github.com/slightlyoff/ServiceWorker/issues 

[Jonas Sicking]

On Wed, Nov 25, 2015 at 4:42 AM, Kinuko Yasuda <kin...@chromium.org> wrote:
>> With a shared worker that is quite easy to do. Simply calling "new
>> SharedWorker(url)" gives you access to an execution context which does
>> that coordination.
>>
>> Additionally this execution context needs to preload data (from
>> network and/or indexedDB) which we expect to be used soon or often and
>> keep it in memory.
>>
>> Right now a lot of this is much harder to do using service workers.
>> But it doesn't need to be. For example I don't see a reason to not
>> enable doing
>>
>> var sw = new ServiceWorker("url");
>> sw.postMessage("...");
>> sw.onmessage = (e) => {...};
>
> I like the brevity but this usage feels very different from today's service
> workers. If we have different usages it feels having different APIs is
> reasonable... while extending the scope of service worker might be worth
> discussing too. For these ideas could we file bugs on SW github if we think
> these should be in the scope of SW?
> https://github.com/slightlyoff/ServiceWorker/issues

Why do you feel like this is a different usage than existing SW usage?
SW is where notifications like push and background sync will go. This
seems ideal for a worker which manages network and database
connections, no?

/ Jonas

[Alex Russell]

I don't understand why this requires anything new. Getting a SW from the registration and then postMessaging to/from it works well. 

Regards