Re: [w3c/ServiceWorker] event.waitUntil/respondWith vs return promise (#1148)

> The browser will want to do this if you're using too much background CPU. It can use extendable events to track which events have granted the service worker additional run time, and that run time can be revoked.

The browser can intervene and terminate based on clear thresholds (time, CPU, storage, etc) in both cases, the `waitUntil` hook doesn't play any role in this. If you passed `sleep(Infinity)` the browser would intervene. If you returned or asynchronously scheduled `sleep(Infinity)` the browser could intervene.

Also note that you took a browser-perspective: I mentioned a _developer_ will never not want to `waitUntil`. If they schedule something but don't also extend the lifetime, that's always a bug. Extra API is useful if it allows developers to do something different. Accordingly, it only has potential downsides (accidentally omitting it), and zero upsides.

> Additionally, waitUntil is used to signal eventual success/failure for multiple events.

The suggestion is that you can simply schedule asynchronous tasks that run to completion or if they trip a quota (e.g. CPU usage), and you can use the return value to signal any eventual extra info (success/failure/response/etc). It might be useful to create a gist to demonstrate if there's a certain task/pattern that you think this wouldn't work for?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1148#issuecomment-306529619