Re: [whatwg] Shared workers with worker parents
On Mon, Jun 22, 2015 at 2:01 PM, Tab Atkins Jr. 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
Re: [whatwg] Shared workers with worker parents
On Fri, Jun 19, 2015 at 3:55 PM, James Burke wrote: > For some of the apps that run on Firefox OS, we want to use a Service > Worker to handle a background sync message, but allow that Service > Worker to contact a Shared Worker to do the work. This allows the > app's open browser windows, which also can trigger a sync, to use the > same Shared Worker to efficiently coordinate the network/database > work. > > There are more details on the use case[1], but the main spec issue: > currently the Shared Worker part of the spec[2] only specifies > Documents as a parent that can keep a Shared Worker alive. > > Would it be possible to change this to also allow any type of Worker > as a parent to a Shared Worker that can keep a Shared Worker alive? > > Is bug 28504[3] enough to track this change, or are there other things > to line up before considering the change? > > Thanks for the insight, > James > > [1] https://github.com/slightlyoff/ServiceWorker/issues/678 > [2] https://html.spec.whatwg.org/multipage/workers.html#dom-sharedworker > [3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=28504 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. ~TJ
[whatwg] Shared workers with worker parents
For some of the apps that run on Firefox OS, we want to use a Service Worker to handle a background sync message, but allow that Service Worker to contact a Shared Worker to do the work. This allows the app's open browser windows, which also can trigger a sync, to use the same Shared Worker to efficiently coordinate the network/database work. There are more details on the use case[1], but the main spec issue: currently the Shared Worker part of the spec[2] only specifies Documents as a parent that can keep a Shared Worker alive. Would it be possible to change this to also allow any type of Worker as a parent to a Shared Worker that can keep a Shared Worker alive? Is bug 28504[3] enough to track this change, or are there other things to line up before considering the change? Thanks for the insight, James [1] https://github.com/slightlyoff/ServiceWorker/issues/678 [2] https://html.spec.whatwg.org/multipage/workers.html#dom-sharedworker [3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=28504
