https://github.com/WICG/shared-storage/pull/199
https://github.com/WICG/shared-storage/pull/209
https://github.com/WICG/shared-storage/pull/211 (anticipated)
https://github.com/WICG/shared-storage/pull/213 (anticipated)
Today, concurrent execution of shared storage worklets can lead to data inconsistencies due to race conditions. To address this issue, we propose integrating the Web Locks API into Shared Storage:
The navigator.locks.request() API is exposed to the shared storage worklet, to be able to request a lock and handle callback after the lock is granted.
All shared storage modifier methods now accept an optional { withLock: <lock name> } parameter. The modifier method will acquire the lock on the designated resource before executing.
A batchUpdate(methods, options) API is introduced in all applicable contexts. It first acquires a lock on the designated resource and then executes methods in order.
The 'Shared-Storage-Write' response header is now treated as a single batchUpdate(), and allows configuring a lock for the entire batch via: "options; with_lock=<lock name>".
The shared storage locks' partition aligns with the shared storage data's partition -- locks are organized by the shared storage origin, and are independent from any locks used in Window or Worker context.
TAG is unsatisfied with the underlying API
Interoperability and Compatibility
The changes are fully backward compatible.
Gecko: No signal
WebKit: No signal
Web developers: Web locks were requested by developers for use with private aggregation.
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Security / Privacy
No concerns. Shared Storage web locks have their own partition which is not readable in normal js contexts. The scope and visibility of Shared Storage web locks aligns with the scope (i.e., per-origin) and visibility (i.e., only the worklet is allowed to read/wait on a lock) of shared storage data.
Shared Storage worklets can be inspected within DevTools: Debug Shared Storage worklets with DevTools
We are working on adding the `withLock` parameter and a `batchUpdate()` event to the Application -> Shared Storage panel in DevTools.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
All but WebView
Is this feature fully tested by web-platform-tests?
Yes
Finch feature name
SharedStorageWebLocks
Requires code in //chrome?
No
Estimated milestones
M133
Link to entry on the Chrome Platform Status
Specificationhttps://github.com/WICG/shared-storage/pull/209
https://github.com/WICG/shared-storage/pull/211 (anticipated)
https://github.com/WICG/shared-storage/pull/213 (anticipated)
On Friday, December 20, 2024 at 6:34:04 PM UTC+1 Josh Karlin wrote:Are there any explainer sections you can point at that won't require reading through PR diffs?
Specificationhttps://github.com/WICG/shared-storage/pull/209
https://github.com/WICG/shared-storage/pull/211 (anticipated)
https://github.com/WICG/shared-storage/pull/213 (anticipated)
Are the "anticipated" parts part of this intent? Are you planning to land those PRs before shipping?
On Thu, Jan 2, 2025 at 9:57 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:On Friday, December 20, 2024 at 6:34:04 PM UTC+1 Josh Karlin wrote:Are there any explainer sections you can point at that won't require reading through PR diffs?It's sort of riddled throughout the explainer but usage within the worklet is documented here and using locks from outside the worklet is described here.
Specificationhttps://github.com/WICG/shared-storage/pull/209
https://github.com/WICG/shared-storage/pull/211 (anticipated)
https://github.com/WICG/shared-storage/pull/213 (anticipated)
Are the "anticipated" parts part of this intent? Are you planning to land those PRs before shipping?Sorry, I should have removed the (anticipated) notes. Yes, they're part of the proposal and will land before shipping.Happy new year!
--
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+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJgi167U-gE2k%3DD1v2rvmbWhXLM8gkx05%2B1XKDHXtB%2BMw%40mail.gmail.com.
LGTM3