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

@bkimmel

> The when is pretty much every SW I've authored since I learned you could call clients.claim(). The why is to stop myself from quietly sobbing in shame for not being able to control SW lifecycles the way I want to 

It sounds like (and there's no shame in this) you're not really sure why you call it or what it does, beyond "it seems to help". Is that fair to say? Which way do you want to control the lifecycle. As in, what would the lifecycle be if you had full control?

> would it maybe send 20x messages home for 20x concurrent SWs? Or can you make it so that just one SW gets the sync and the other ones you spun up don't?

No, no global event would be duplicated. If you're getting one event for it today, you'll still get one event for it in this concurrent model. Currently, if 50 distinct fetch events need to be fired, they'll happen in the same SW instance unless the SW is terminated in between. In the concurrent model, the 50 fetch events will be load-balanced across multiple instances, but the total number of fetch events will still be 50.

> But more generally, any pattern where I wait in the SW for a message from the client... since as it was pointed out above, now I have absolutely no idea which evil SW twin will get the message to proceed

We're looking for cases where that would matter. It should only matter if you're holding state in the global scope, which is already unreliable but will become more unreliable. Are you doing that?

---
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-238025872