Web Locks API: Snapshot order of held locks deviates from spec |
||||
Issue descriptionWhen query() is used, an ordered list of requested and held locks is produced. Per spec, the list of held locks is an *ordered set*. The locks are placed in the set when granted. The set is traversed in order to produce the response for query() The Chrome implementation produces the snapshot by iterating a map of id->lock. The IDs are produced when the request comes in. If the request order doesn't match the grant order, this won't match the spec. This could occur in two ways: * Changes to lock granting algorithm, e.g. if we allow a grantable SHARED lock to be granted ahead of a blocked EXCLUSIVE lock. * Stealing, which allows a newer lock request to slip ahead of other requests.
,
Jan 30 2018
,
Feb 5 2018
,
Feb 6 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4d37dc96e6039a1b0991c2081bb6e00d591776de commit 4d37dc96e6039a1b0991c2081bb6e00d591776de Author: Joshua Bell <jsbell@chromium.org> Date: Tue Feb 06 21:12:10 2018 Web Locks API: Ensure snapshot order of held locks matches spec The proto-spec defines requested locks as an ordered set, ordered by request order, and granted locks as an ordered set, ordered by grant order, which can differ. The order is visible using the query() API. Add tests to ensure that an implementation doesn't re-use the request order for the granted order, or use unordered sets, etc. Bug: 807016 Change-Id: I8b82db794b5d4431e7873dbb78c8f9f81064db40 Reviewed-on: https://chromium-review.googlesource.com/892143 Commit-Queue: Joshua Bell <jsbell@chromium.org> Reviewed-by: Victor Costan <pwnall@chromium.org> Cr-Commit-Position: refs/heads/master@{#534792} [add] https://crrev.com/4d37dc96e6039a1b0991c2081bb6e00d591776de/third_party/WebKit/LayoutTests/http/tests/locks/query-order.html
,
Feb 7 2018
|
||||
►
Sign in to add a comment |
||||
Comment 1 by jsb...@chromium.org
, Jan 29 2018