Intent to Implement: Web Locks API
Joshua Bell
Contact emails
jsb...@chromium.org (but darin@ should get credit too)
Explainer
https://github.com/inexorabletash/web-locks
Design doc/Spec
Summary
A new web platform primitive API that allows agents (tabs, workers) within an origin to coordinate use of abstract shared resources. This is equivalent to a "mutex" as exposed by many operating systems, with additional optional lock types (exclusive and shared) for common scenarios.
navigator.locks.acquire("my_resource", async lock => {
// can assert that no other tab/worker in this origin
// is using "my_resource" until this async function completes
});
The locks/resources have no meaning themselves outside of the API; it's up to the application to use them to bound the use of other APIs, e.g. to make sure only one tab is fetching a data from the network and writing it to the database.
Motivation
Existing web properties that manage cross-tab behavior use a variety of approximations to achieve this: polling against Indexed DB, tracking clients with Service Workers and BroadcastChannel, or requiring Shared Workers. All of these have significant gaps and complexity.
Risks
Interoperability and Compatibility
New feature; risk is lack of adoption. It does not introduce complexity for other parts of the code base.
Edge/Firefox/Safari: No signals
Web developers: Interest from Google Docs and Gmail.
Ergonomics
Likely to be used with various agent types (e.g. Windows, Service Workers) and to coordinate use of other APIs (e.g. which tab gets to fetch, which tab gets to write to the database, etc). The API is entirely async and can be used from any context.
Feature depends on AbortController/AbortSignal for some functionality. Since that is NYI, we can stage the implementation.
Like other APIs that hold stateful resources and/or resources visible across tabs (BroadcastChannel, Indexed DB, Web Sockets, ...) the interaction with the Web Lifecycle API will require careful specification. (e.g. can we suspend a tab holding a lock?)
Activation
The feature would be usable as-is. Polyfills would be flawed due to limitations in the existing APIs - it would require poling, and/or a service worker, and/or shared workers (but have gaps); developers would likely need to pick the least-worst approach to work around this gap (as they do today); there would not be a simple drop-in.
Debuggability
Based on experience with debugging IndexedDB (etc), the API itself is designed to include debugging support so that web applications can introspect their state (what locks are held? what locks are pending?) and reset that state (potentially controversial, added but based on feedback from likely consumers of the API)
Exposing an inspector for held locks in DevTools might be valuable too.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Is this feature fully tested by web-platform-tests?
In-progress CL has testharness.js-based test coverage. These would land as .tentative tests in WPT during the implementation phase.
Link to entry on the feature dashboard
Will file if/when stuff lands.
Requesting approval to ship?
No. Plan to have the feature available behind a flag until the API is stable, then proceed to "intent to experiment".
Joe Medley
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD649j5Xt3m5hWd3jxqAjHH2XFcud%2BSrJeF-5avKs2FjHPOV_w%40mail.gmail.com.
