search

w3c / ServiceWorker

Service Workers
https://w3c.github.io/ServiceWorker/
Other
3.63k stars 315 forks source link

ServiceWorker Longevity #840

Closed RichardMaher closed 8 years ago

RichardMaher commented 8 years ago

WRT: - https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope

Once successfully registered, a service worker can _and will_ be terminated when idle to conserve memory and processor power. An active service worker is automatically restarted to respond to events,

Can anyone please confirm that the Mozilla documentation is wrong, or at least out of date?

There is certainly nothing in the spec (I can see) that mandates the immediate culling of viable and reusable SWs as soon as the event queue is empty.

I can see no evidence of the wisdom of a strategy that seeks to conserve memory and processor power by enduring the performance hit of re-initializing a SW for almost every event. Surely a simple TTL parameter on the registration backed up by a browser options parameter could do the necessary?

Perhaps just leave the thing up on the understanding that the OS knows best and can terminate at will? (If memory footprint stats are a justification then see TTL)

I can understand the school of thought that once said SW events "will only ever be Message events and they only everyhappen will big intervals" but I think scope creep is inevitable with this amazing functionality and the number of event-types is already multiplying like rabbits.

Depending on the throttle options set on : - serviceWorkerRegistration.travelManager.subscribe({opions. . .})

GPS readings could be coming through for every 10 meter delta. Once the new Location has been XHRed and self.postMessaged the SW is still active and waiting for another event. Makes sense?

wanderview commented 8 years ago

The spec is written such that the browser can kill the service worker thread whenever it thinks make sense. In practice, both chrome and Firefox implement a grace period before terminating the thread.

The MDN text is strongly worded to discourage people from relying on global state. Note, however, it does not state the definition of "idle".

RichardMaher commented 8 years ago

Cool bananas! Thanks for explaining Ben. Makes much more sense.

RichardMaher commented 7 years ago

@wanderview could you please find the time to give your opinion over here as to whether you agree that the potential for a favourable ratio if Service-Workers-Instantiated to GeoLocation position-updates received is very real?

Clearly the filtering/throttle options on the TravelManager registration will affect the outcome (and I'm not even going to cheat by setting maxInterval < SW_grace-period :-) but if you and your colleagues could comment on the soundness of the design proposal, I would be very grateful.

Also, why not just give us a typical grace period example or the name of the system parameter that governs it?

NB: That's even if you don't agree with me and I'm wrong. Happy to stop carrying on about it if it is a silly idea!