Re: [slightlyoff/ServiceWorker] consider allowing multiple worker thread instances for a single registration (#756)

> Result: 2 requests to the server, 2 caching operations ? Or i miss something ?

Yes, you could have 2 requests to the server.  But this is no different than with a single thread handling two overlapping FetchEvents.

> This open the door to create a process for each fetch request ?

It would leave it up to the browser to decide where to dispatch the FetchEvent.  It would be allowed to spawn a new process for each one, but I think its highly unlikely any browser would actually implement it that way.  We would be trying to focus on running it where the FetchEvent would have the quickest response time.

> As said by wheresrhys, call indexedDB to store globally a state on each fetch or postmessage event can become a pb for performances ?

The question is, are people relying heavily on global state today given that the service worker can be killed whenever you are out of the waitUntil() anyway?  If you are doing anything with global state outside of waitUntil then you need to use IDB even with a single SW thread.

We're trying to understand what the use cases for global state across events within a waitUntil() are today.  Without seeing the use cases its hard to know if IDB is too heavy-weight.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/756#issuecomment-237880540