Re: [w3ctag/design-reviews] Extended lifetime shared workers (Issue #1089)

jyasskin left a comment (w3ctag/design-reviews#1089)

Hi @domenic. Sorry that we were unclear in describing the idea. We wanted to try to address the unnecessarily long lifetimes and WebLock-based hangs by ensuring that the SharedWorker only stays alive as long as the developer is actively using it, instead of the fixed lifetime caused by the `extendedLifetime: true` flag. The [`extendLifetimeUntil()` function](https://github.com/whatwg/html/issues/10997#issuecomment-2895223470) based on [`ExtendableEvent`s](https://developer.mozilla.org/en-US/docs/Web/API/ExtendableEvent/waitUntil) seems to accomplish that, but, as @asutherland [pointed out](https://github.com/whatwg/html/issues/10997#issuecomment-2896661453), implementations need to know if it's _going to be called_ before the SharedWorker starts.

`SharedWorker.runCleanupOnExit(url, item)` is meant to do this. It should _not_ start the SharedWorker when it's called, as that would waste memory between that time and the time that the page closes. Instead, it would serialize `item` and instruct the browser that an extendable SharedWorker needs to be started whenever the page closes.

Does that make more sense?

This doesn't address the case of a page that needs the same SharedWorker both during its lifetime and to do cleanup, and it doesn't help if the primary or only use for this is to be called from a `pagehide` event handler.... I haven't checked this with the rest of the TAG, but I think we'd get the same benefits if `new SharedWorker(url, { extendedLifetime: true });`, instead of always extending the lifetime for 30 seconds (depending on the browser), just enabled the `extendLifetimeUntil()` global function.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1089#issuecomment-3230070200
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1089/3230070200@github.com>