- From: Yoshisato Yanagisawa <notifications@github.com>
- Date: Tue, 25 Feb 2025 01:40:25 -0800
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/pull/1755/review/2640335718@github.com>
@yoshisatoyanagisawa commented on this pull request. > @@ -2261,10 +2267,11 @@ spec: storage; urlPrefix: https://storage.spec.whatwg.org/ The <dfn method for="CacheStorage"><code>match(|request|, |options|)</code></dfn> method steps are: 1. If |options|["{{MultiCacheQueryOptions/cacheName}}"] [=map/exists=], then: - 1. Return [=a new promise=] |promise| and run the following substeps [=in parallel=]: + 1. Let |promise| be [=a new promise=]. + 1. Run the following substeps [=in parallel=]: I assume that Cache API can be executed in parallel. Then, there can be a case that a |cacheName| map is deleted while a |cacheName|'s map is being accessed. To prevent that happen, I guess access to the [=relevant name to cache map=] must not happen in parallel. For the purpose, there might need to be a dedicated parallel queue in https://w3c.github.io/ServiceWorker/#cache-constructs, and all actions to the CacheStorage may need to be happen within the parallel queue. I mean for `match()`, `has()`, `open()`, and `delete()`, they should be executed within the cache constructs's parallel queue. 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. What do you think? -- Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/pull/1755#discussion_r1969379527 You are receiving this because you are subscribed to this thread. Message ID: <w3c/ServiceWorker/pull/1755/review/2640335718@github.com>
Received on Tuesday, 25 February 2025 09:40:29 UTC