Add extended lifetime shared workers#11600
Conversation
|
Any blockers on this PR? |
asutherland
left a comment
There was a problem hiding this comment.
Looks great, especially in conjunction of your recent set of cleanups, thank you! I very much appreciate the non-normative sections which provide a lot of invaluable context and clarity.
cb9905b to
b845273
Compare
|
Thank you for the update. |
I'd like to land whatwg/html#11600, and that requires verifying Domenic as an individual after he retired.
domfarolino
left a comment
There was a problem hiding this comment.
This PR is ready to merge. I've filed the remaining implementation bugs, MDN issue, and wrote a suitable commit message in the OP that I'll use when merging. As noted below, there is one small bug which I will fix before merging.
|
OK this is ready to merge. I was initially worried there was more to figure with the interaction between shared workers, web locks, and bf-cache, but I don't think there's any work to do in this PR. There are some interesting forced-eviction scenarios to think about:
We don't spec when a browser must evict documents from the bf-cache, I think. But we probably want to offer more guidance or otherwise draw attention to these scenarios in which browsers may want to perform eviction. Maybe that can be part of #11520. Anyways, the reason any of this relates to extended lifetime shared workers at all, is because (2) above. Extended lifetime shared workers basically turn (2) into (2.i), by letting a shared worker with no active clients keep running as if it did have an active client. This allows for a footgun captured by @fergald in #10997 (comment), where a shared worker is designed to hold a lock until a client document tells it to release, but that client first goes into the bf-cache. A second document that comes around and requests the lock will be waiting for N minutes (the duration of the extended lifetime) on the lock. Such a case is caused by a poorly designed worker and doesn't need special treatment in the spec, besides optional guidance as part of the work above. |
BFCache is an optional optimization but there are some cases where it is definitely not OK to use it and we spec those. Most of them have been cases where we don't allow the page into BFCache but I'm pretty sure @rubberyuzu added at least one case where we evict from BFCache. |
|
To avoid scattering the discussions, I suggest to continue the discussion in #11520. Let me comment there. |
This CL moves the SharedWorker-extendedLifetime tests from tentative/ to the regular workers/ directory as the feature is now in the HTML standard. whatwg/html#11600 Bug: 400473072 Change-Id: Iadd0dc398392cc0edc502e4a774b9d38c0b9fb5e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7734182 Auto-Submit: Yoshisato Yanagisawa <yyanagisawa@chromium.org> Commit-Queue: Yoshisato Yanagisawa <yyanagisawa@chromium.org> Reviewed-by: Minoru Chikamune <chikamune@chromium.org> Cr-Commit-Position: refs/heads/main@{#1610600}
This CL moves the SharedWorker-extendedLifetime tests from tentative/ to the regular workers/ directory as the feature is now in the HTML standard. whatwg/html#11600 Bug: 400473072 Change-Id: Iadd0dc398392cc0edc502e4a774b9d38c0b9fb5e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7734182 Auto-Submit: Yoshisato Yanagisawa <yyanagisawa@chromium.org> Commit-Queue: Yoshisato Yanagisawa <yyanagisawa@chromium.org> Reviewed-by: Minoru Chikamune <chikamune@chromium.org> Cr-Commit-Position: refs/heads/main@{#1610600}
This CL moves the SharedWorker-extendedLifetime tests from tentative/ to the regular workers/ directory as the feature is now in the HTML standard. whatwg/html#11600 Bug: 400473072 Change-Id: Iadd0dc398392cc0edc502e4a774b9d38c0b9fb5e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7734182 Auto-Submit: Yoshisato Yanagisawa <yyanagisawa@chromium.org> Commit-Queue: Yoshisato Yanagisawa <yyanagisawa@chromium.org> Reviewed-by: Minoru Chikamune <chikamune@chromium.org> Cr-Commit-Position: refs/heads/main@{#1610600}
This PR introduces extended lifetime shared workers as a lightweight alternative to e.g., Service Workers, to perform complex, async operations after document unloading. Specifically, this PR introduces the
SharedWorkerOptionsdictionary and itsextendedLifetimeboolean member. Together, they allow a SharedWorkerGlobalScope's lifetime to be extended by an implementation-defined time, when it would otherwise be suspendable.Before this, a shared worker whose owner set is empty or contains only non-fully-active owners would not be "actively needed" or "protected"; it would be thus suspendable for the duration of its https://html.spec.whatwg.org/#between-loads-shared-worker-timeout, or for as long as it has clients, respectively. This is useful for keeping the worker around for a bit so that it doesn't need to be re-initialized from scratch later, but it doesn't guarantee that the worker can perform any last-minute work in this period. Extended lifetime shared workers allow the worker to stay "actively needed" and thus not "suspendable" during the extended lifetime timeout. This ensures they keep running until the timeout expires.
See https://gist.github.com/domenic/c5bd38339f33b49120ae11b3b4af5b9b for an explainer. Closes #10997.
(See WHATWG Working Mode: Changes for more details.)
/infrastructure.html ( diff )
/workers.html ( diff )