Re: [service-workers] A pattern for preventing worker termination indefinitely

What you propose doing should generally work.  You can be way lazier
about keep-alives than 100ms.

As long as you have an active page, you should be able to keep its
controlling service worker alive.  (Or really, any non-"redundant" SW
since you can postMessage all states but redundant.)  Most efforts to
stop bad behavior are concerned about Service Workers that try and
remain alive indefinitely without a page.  For example, trickery where 2
SW's message each other to try and reset the keepalive timers like a
page had issued the message.

It's a fairly common idiom in the existing ServiceWorker WPT tests and
browser-specific tests (at least for Gecko) to use waitUntil in a SW to
keep it alive until the page says it should be terminated.

For awareness, Gecko's current timeout settings can be found here:
http://searchfox.org/mozilla-central/source/modules/libpref/init/all.js#157
They are:
* Service Workers will stay alive on their own for 30 seconds after the
last event was initiated
* Service Workers can be kept alive via waitUntil for at most 5 minutes.
 This should provide sufficient confidence that the tests won't
intermittently fail unless they're really slow.

Having said all that, it sounds like you want to keep a single
ServiceWorker alive for an extended period of time, and I'm not sure I
get why that is.  I may be parsing your initial "a way to consistently
track the state of a worker over time" problem statement incorrectly,
but the ServiceWorker binding[1] exposes the "state" of the worker at
all times (subject to propagation across threads, and which you can deal
with by listening for "statechange" events).

Andrew

1: https://w3c.github.io/ServiceWorker/#serviceworker-interface

Received on Monday, 13 March 2017 19:20:48 UTC