Skip to content

Simplify orphan worker closing#12182

Open
domfarolino wants to merge 2 commits intomainfrom
simplify-orphan-worker-closing
Open

Simplify orphan worker closing#12182
domfarolino wants to merge 2 commits intomainfrom
simplify-orphan-worker-closing

Conversation

@domfarolino
Copy link
Copy Markdown
Member

@domfarolino domfarolino commented Feb 19, 2026

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:

  • We definitely want the lower-bound of auto-closing a worker only after it's no longer protected. But why do we have an upper bound of "no later than it stops being permissible"? Why must the worker be permissible when we auto-close it? What's wrong with auto-closing an un-protected, impermissible one? Maybe that's "too late"? This PR removes the upper bound of this condition.
  • If my reading is correct, the spec currently auto-closes shared workers right when all their owner documents go into the bf-cache, or when they have no documents and are still within the "between-loads shared worker timeout", and thus permissible. Why do we want to auto-close those workers? Doesn't that mean right when their current task is finished, the event loop will stop processing new tasks and will ultimately shut down, even if a subsequent navigation to a new Document tries to connect to that shared worker, and it becomes "actively needed" again? Isn't this exactly what the between-loads shared worker timeout is trying to protect against? It seems so, given the prose in https://html.spec.whatwg.org/#note-between-loads-shared-worker-timeout-lifetime.

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 )

@domfarolino
Copy link
Copy Markdown
Member Author

@yoshisatoyanagisawa could you take a look at this too?

@yoshisatoyanagisawa
Copy link
Copy Markdown
Contributor

I think the Chromium behavior is near to this, and I prefer this simpler way.

@domfarolino domfarolino requested review from zcorpan and removed request for annevk March 26, 2026 16:44
@domfarolino
Copy link
Copy Markdown
Member Author

Hey @asutherland, would you mind taking a look at this (and the OP/rationale above)?

<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>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

3 participants