Intent to Experiment: Web Locks API

[Joshua Bell]

Contact emails

jsb...@chromium.org, pwn...@chromium.org

Spec

Explainer: https://github.com/inexorabletash/web-locks

Proto-spec: https://github.com/inexorabletash/web-locks/blob/master/proto-spec.md

Summary

A new web platform primitive API that allows parts of a web app running in different tabs/workers 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 database/filesystem scenarios.

navigator.locks.request("my_resource", async lock => {

  // can assert that no other tab/worker in this origin

  // is using "my_resource" until this async function completes

});

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/DpODIjdpUMg/hVQkjqeIAAAJ

Several changes have been made to the API specifics since the I2I: rename of the introductory method, several new options, etc.

Goals for experimentation

The API expresses a new "platform primitive" and subtle one. Locks are hard, and potentially give web applications enough power to shoot themselves in the foot. Are we striking the right balance with the design here?

• Potential confusion with other lock APIs (Wake/Keyboard/Pointer/Orientation Lock, etc.) - this is a different beast since it's not requesting exclusive use of a system resource. All of those have different API shapes. How much alignment should we do?
• API shape - after much iteration, we settled on a novel pattern (an async callback) to encourage concise code and encourage holding locks for minimal time. Will that be used as designed, or will everyone end up wrapping the API in a similar way? Too much groupthink?
• Some of the management features of the API (query, steal) are requested by users, but potentially confusing for developers that have different use cases in mind. Will they make the surface area too confusing, or be mis-used?
• We've requested/received TAG feedback about some of these issues, but don't agree with all of it. We want to know what developers think.
• Is anything glaring missing?

In addition, some of the potential users of the API may run experiments comparing performance of the API against current workarounds (such as database polling).

Experimental timeline

Proposed to launch OT in 66 and run through 67, iterating if necessary based on feedback.

Any risks when the experiment finishes?

No; no persisted data.

Ongoing technical constraints

None.

(To align client IDs with Service Workers we will likely alter where the IDs are generated, but that is probably for the best anyway.)

Debuggability

The navigator.locks.query() method allows introspection of a web app's use of the feature, and can be called from the console. (Locks should be ephemeral, except when they aren't and that's when the method is handy.) No other DevTools support yet.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5712361335816192

[Rick Byers]

LGTM

I know we have at least one big customer within Google.   I'm hopeful having hard data from their experience experimenting will help make the spec debates more concrete.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD649j5Sm5oAx4m9-o8mSj96hrzwSB0k6R-V_CSwGzpK1Qf0tQ%40mail.gmail.com.