Skip to content

Comments

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
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
Member Author

@yoshisatoyanagisawa could you take a look at this too?

@yoshisatoyanagisawa
Copy link
Contributor

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

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.

2 participants