You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some browser implementations may want to put browsing contexts "to sleep" without terminating them. Do these retain the flag, or lose it? Is there a signal for "you thought you were holding the flag but nope" ?
I'd even go for the harsher stance of: if you're holding a resource you don't even get suspended, you just get discarded. If you are holding resources and don't want to get discarded, well then you'd better release the resources during the event.
Some use cases (e.g. document editors), the intent would be that the lock is held for (almost) the lifetime of the tab, and re-acquiring (and initializing state) is comparable to reloading. So a vote for allowing suspended tabs to hold locks.
Consensus seems to be emerging in discussions that suspended tabs retain hold of the locks, presuming that the tab is given notification that it is about to be suspended.
Locks should never be stolen/broken by the user agent when a tab is suspended. Any logic like "if tab is holding exclusive access to a resource, do not suspend that tab but discard it instead" would be up to the user agent (since suspend vs. discard is a UA-specific heuristic anyway).
Also, re: the "...presuming that the tab is given notification..." bit - do we need to transitively guarantee that for workers/iframes? Presumably yes...
... suspended tabs retain hold of the locks, presuming that the tab is given notification that it is about to be suspended.
Yes the tab is notified of suspension via the "onfreeze" callback. However if they can retain holding the lock then why does it matter that there is a callback?
(sorry I'm confused)
It's not necessary for the API to be consistent, but for a web app it allows a tab to relinquish the lock, e.g. so some other tab could be elected. For example, one tab is holding the "I get to sync app state to the network" lock, other tabs just delegate to it. If that tab gets "onfreeze" it can drop the lock so another tab can pick it up and network syncing continues. If we didn't have such an event then syncing would freeze. (And just "breaking" the lock would be bad because another tab would be elected, but when unfrozen both tabs would believe they can sync.)
In other use cases, just holding the lock even while frozen is the right thing.
Activity
jakearchibald commentedon Oct 2, 2017
An
AbortSignalcould be used as a notification method here.jakearchibald commentedon Oct 3, 2017
Alternatively, if a flag is requested that's owned by a CPU-suspended tab, we could just discard the suspended tab.
inexorabletash commentedon Oct 3, 2017
SGTM.
I'd even go for the harsher stance of: if you're holding a resource you don't even get suspended, you just get discarded. If you are holding resources and don't want to get discarded, well then you'd better release the resources during the event.
inexorabletash commentedon Oct 3, 2017
From offline discussion:
Some use cases (e.g. document editors), the intent would be that the lock is held for (almost) the lifetime of the tab, and re-acquiring (and initializing state) is comparable to reloading. So a vote for allowing suspended tabs to hold locks.
annevk commentedon Nov 13, 2017
Note that for SharedArrayBuffer we don't do anything special for these kind of documents: whatwg/html#2581.
inexorabletash commentedon Jan 18, 2018
cc: @spanicker
Consensus seems to be emerging in discussions that suspended tabs retain hold of the locks, presuming that the tab is given notification that it is about to be suspended.
Locks should never be stolen/broken by the user agent when a tab is suspended. Any logic like "if tab is holding exclusive access to a resource, do not suspend that tab but discard it instead" would be up to the user agent (since suspend vs. discard is a UA-specific heuristic anyway).
Seem reasonable?
inexorabletash commentedon Jan 18, 2018
Also, re: the "...presuming that the tab is given notification..." bit - do we need to transitively guarantee that for workers/iframes? Presumably yes...
spanicker commentedon Jan 19, 2018
Yes the tab is notified of suspension via the "onfreeze" callback. However if they can retain holding the lock then why does it matter that there is a callback?
(sorry I'm confused)
inexorabletash commentedon Jan 19, 2018
It's not necessary for the API to be consistent, but for a web app it allows a tab to relinquish the lock, e.g. so some other tab could be elected. For example, one tab is holding the "I get to sync app state to the network" lock, other tabs just delegate to it. If that tab gets "onfreeze" it can drop the lock so another tab can pick it up and network syncing continues. If we didn't have such an event then syncing would freeze. (And just "breaking" the lock would be bad because another tab would be elected, but when unfrozen both tabs would believe they can sync.)
In other use cases, just holding the lock even while frozen is the right thing.
spanicker commentedon Jan 19, 2018
Thanks for the context, that makes sense!
onfreeze is guaranteed before suspension (and we also want to fire it before throttling interventions)