Editorial: use a per-cache dedicated parallel queue for Cache API methods

[monica-ch]

Closes #1841. Follow-up to #1755, sibling to #1838.

Give each [=request response list=] (the internal representation of a {{Cache}} object) a dedicated parallel queue and route the {{Cache}} methods that read or mutate it through the queue, so reads and writes on the same {{Cache}} object are serialized.

Changes

• Add <dfn>request response list parallel queue</dfn> (a [=parallel queue=]) attached to each [=request response list=], following the same pattern that Editorial: serialize CacheStorage access on a dedicated parallel queue #1838 introduced for the [=name to cache map=].
• Route the following {{Cache}} method algorithms through it, replacing their existing Run … in parallel block:
  • {{Cache/matchAll(request, options)}}
  • {{Cache/addAll(requests)}} — only the batch-commit step; the per-request fetch step is left as bare in parallel since it does not touch the [=request response list=].
  • {{Cache/put(request, response)}}
  • {{Cache/delete(request, options)}}
  • {{Cache/keys(request, options)}}
• The existing Queue a task wrappers around promise resolution / rejection (from Editorial: queue a task in Cache API #1837) are preserved inside the enqueued steps.

Total change: +7 / −5 in index.bs, one commit.

Out of scope (deliberately)

• {{Cache/match(request, options)}} — a pure orchestrator that delegates to matchAll; enqueueing it too would cause a deadlock (it waits on a promise that can only be settled by another enqueued step). Covered transitively.
• {{Cache/add(request)}} — pure orchestrator that delegates to addAll. Same reason.
• {{Cache/addAll}}'s per-request fetch block — only performs [=/fetching=]; does not touch the [=request response list=].

Rationale

Yoshi flagged this concern during #1755 review:

The situation should also be the same for the [=cache=] object. I guess each [=cache=] object will have the dedicated parallel queue, and match(), matchAll(), add(), addAll(), put(), delete(), and keys() might also executed within the parallel queue for the [=cache=] object.

#1837 landed the queue-a-task-for-resolve fixes for these methods. This PR delivers the sibling per-cache parallel-queue work that was explicitly deferred in the split plan.

Coordination

The changes here do not overlap textually with the queue-a-task changes in #1837 — that PR only touches the promise resolve/reject lines, this PR only touches the outer Run in parallel lines. Either can merge first.

Related

• Editorial: Queue a task to resolve/reject promise or when fire an event. #1755 — parent (queue-a-task refactor)
• Editorial: queue a task in Cache API #1837 — Cache API queue-a-task-for-resolve (open)
• Editorial: serialize CacheStorage access on a dedicated parallel queue #1838 — sibling PR (CacheStorage name to cache map parallel queue), same dfn pattern
• Missing tasks in parallel steps in Service Workers Nightly #1740 — original missing-tasks-in-parallel issue
• cache and cache-storage algos forgets to queue a task to resolve promise. #1831 — cache/cache-storage forgot to queue a task to resolve promise
• Carefully audit all uses of "in parallel" in the spec #1172 — umbrella "Carefully audit all uses of 'in parallel' in the spec"
• Editorial: use a dedicated parallel queue for the Clients API #1842 — sibling PR (Clients API parallel queue), same dfn pattern

---

Preview | Diff