- From: Mike Pennisi <mike@bocoup.com>
- Date: Mon, 13 Mar 2017 12:48:55 -0400
- To: Webapps WG <public-webapps@w3.org>
Hi folks, This posting's title may raise some eyebrows, but I think my intent is well-founded. I'm working on Service Worker specification tests for the Web Platform Tests project [1], and I need a way to consistently track the state of a worker over time. Many existing tests simply store this state globally and report it to the client upon request. However, since a worker "may be killed by the user agent at nearly any time," this is susceptible to race conditions. Preventing worker termination would allow tests to be written safely without requiring additional technologies (e.g. IndexedDB) or having to account for duplicative readings. I think I can do this using the current API through a client-worker protocol that indefinitely creates short-term holds on sequential events: 1. Client 1. Unregister service worker 2. Register service worker 2. Service worker (`install` event handler) 1. Create Promise named `installHold` 2. Invoke event's `waitUntil` method with `installHold` 3. Store `installHold` globally as `previousHold` 3. Client (on fulfillment of `register` promise) 1. Store "installing" working globally as `oldestWorker` 4. Client 1. Wait 100 milliseconds 2. postMessage to `oldestWorker`: "release hold" 5. Service worker (`message` event handler) 1. Create Promise named `messageHold` 2. Invoke event's `waitUntil` method with `messageHold` 3. Resolve `previousHold` 4. Store `messageHold` globally as `previousHold` 6. Repeat steps 4 and 5 indefinitely By my reading, this would prevent the browser from terminating the "oldest" worker indefinitely--assuming that the timer's interval in step 4 does not exceed "imposed time limits." (Holding on the `install` event is necessary to avoid termination before the cyclic `message` holding pattern can be established). This pattern is generally antithetical to the design of the Service Worker API, so it would not be advisable for use in application contexts. That said, I'm wondering if folks here think it is reliable for use in specification tests. It could be simplified by configuring the worker to send the "release hold" messages to itself, but I worry that browsers may detect this behavior and force termination. Can anyone speak to that? Thanks! Mike [1] https://github.com/w3c/web-platform-tests/tree/master/service-workers
Received on Monday, 13 March 2017 16:49:30 UTC