W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2017

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

From: Andrew Sutherland <asutherland@asutherland.org>
Date: Mon, 13 Mar 2017 15:20:21 -0400
Message-Id: <1489432821.741412.909943816.5EEB997E@webmail.messagingengine.com>
To: public-webapps@w3.org
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:
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).


1: https://w3c.github.io/ServiceWorker/#serviceworker-interface
Received on Monday, 13 March 2017 19:20:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:15:04 UTC