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

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