W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2015

Re: [whatwg] Shared workers with worker parents

From: James Burke <jrburke@gmail.com>
Date: Mon, 22 Jun 2015 17:19:46 -0700
Message-ID: <CAHgY_icdXbzYaZKXT+CabO7_4sCYWT6MkJkLMnz7xM4yWez0EQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: WHATWG <whatwg@lists.whatwg.org>
On Mon, Jun 22, 2015 at 2:01 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> How can a ServiceWorker keep a SharedWorker alive, when a
> ServiceWorker does not, itself, have any lifetime guarantees?  In
> fact, it's virtually guaranteed to be shut down regularly.

Service workers will be used for some browser-initiated messages, like
backgroundsync, and those entry points allow returning a promise via
event.waitUntil that will keep the service worker up for a little bit
for that message to be processed. A speculative example:

https://github.com/slightlyoff/ServiceWorker/issues/678#issuecomment-92992257

In that use case, the email app wants the shared worker to do the
actual sync work, since it could be running anyway if a window/tab is
open for some email UI.

It should still be the case that the browser makes the ultimate
decision, and could decide regardless of the waitUntil promise
resolving, to terminate the service worker, and therefore the shared
worker, due to other pressures. Like on a mobile device killing
non-foreground processes to give the foreground more memory.

However, if the browser's heuristics are fine waiting for the
waitUntil promise to resolve, the hope is to allow the service worker
to ask the shared worker to do the sync work and wait for the shared
worker to respond back indicating the sync is complete.

Besides issue 678 in the ServiceWorker repo, more background info on
the use case and conversation around it in:

https://github.com/slightlyoff/BackgroundSync/issues/70

James
Received on Tuesday, 23 June 2015 00:20:14 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:33 UTC