Re: [w3c/ServiceWorker] Editorial: Queue a task to resolve/reject promise or when fire an event. (PR #1755)

@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