Reconcile with document lifecycle

[inexorabletash]

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" ?

See https://github.com/spanicker/web-lifecycle

[jakearchibald]

An AbortSignal could be used as a notification method here.

[jakearchibald]

Alternatively, if a flag is requested that's owned by a CPU-suspended tab, we could just discard the suspended tab.

[inexorabletash]

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]

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]

Note that for SharedArrayBuffer we don't do anything special for these kind of documents: whatwg/html#2581.

[inexorabletash]

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]

Also, re: the "...presuming that the tab is given notification..." bit - do we need to transitively guarantee that for workers/iframes? Presumably yes...

[spanicker]

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

[inexorabletash]

why does it matter that there is a callback?

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]

Thanks for the context, that makes sense!
onfreeze is guaranteed before suspension (and we also want to fire it before throttling interventions)