- From: Andrew Sutherland <asutherland@asutherland.org>
- Date: Mon, 13 Mar 2017 15:20:21 -0400
- 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: 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