Open
Conversation
Member
Author
|
@yoshisatoyanagisawa could you take a look at this too? |
Contributor
|
I think the Chromium behavior is near to this, and I prefer this simpler way. |
Member
Author
|
Hey @asutherland, would you mind taking a look at this (and the OP/rationale above)? |
annevk
reviewed
Mar 30, 2026
| <code>SharedWorkerGlobalScope</code> with no current owners being kept alive for the duration of | ||
| the <span>between-loads shared worker timeout</span>.</p></li> | ||
| <code>SharedWorkerGlobalScope</code> whose <span>owner set</span> has been empty so far for less | ||
| than the duration of the <span>between-loads shared worker timeout</span>.</p></li> |
Member
There was a problem hiding this comment.
I find this a bit vaguer. Maybe with "so far" dropped it's better?
| they stop being <span data-x="protected worker">protected</span> and when they stop being <span | ||
| data-x="permissible worker">permissible</span>.</p></li> | ||
| <li><p>Workers get <a href="#step-closing-orphan-workers">closed as orphans</a> when they are no | ||
| longer <span data-x="protected worker">protected</span>.</p></li> |
Member
There was a problem hiding this comment.
Doesn't this mean that a shared worker cannot be closed as orphan anymore?
| worker">protected</span>, and no later than it stops being <span data-x="permissible | ||
| worker">permissible</span>, <var>worker global scope</var>'s <span | ||
| <var>worker global scope</var> such that anytime after it stops being <span data-x="protected | ||
| worker">protected</span>, <var>worker global scope</var>'s <span |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Before this PR, workers were to be monitored and considered as "orphaned" (and subsequently closed), when they finally stopped being "protected", but while they were still "permissible". This was reiterated by this note which says: "Workers get closed as orphans between when they stop being protected and when they stop being permissible."
I understand the lower bound of waiting until a worker is no longer protected to consider it orphaned. For dedicated workers, that covers this actively-needed-but-not-protected worker that's barely hanging on to its existence, simply because its event loop hasn't yielded yet. For shared workers, they are always protected as long as they have an active document owner, so these workers would only get auto-closed when all of their owners are inactive in the bf-cache, or disappear between navigations.
There are two things I notice from this:
These algorithms are very complicated and it's possible I've overlooked something simple, but I want to raise it here to confirm one way or another. This PR only addresses the first point above about removing the upper bound, allowing us to auto-close workers that are no longer protected, even if they are no longer permissible.
If folks deem the second point in my list above to be a bug as I suspect it is, we should fix that separately.
/workers.html ( diff )