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. |
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 )