- From: James Burke <jrburke@gmail.com>
- Date: Mon, 22 Jun 2015 17:19:46 -0700
- 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