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

> Follow-up question: I've used patterns in the past of "hanging" a service worker mid-lifecycle with event.waitUntil until "things" happen (some record appears in IndexedDB, a message from the client... see https://github.com/bkimmel/bkimmel.github.io/blob/master/serviceworker_bgs/sw.js ). It seems like if there were multiple SWs running, those wouldn't really be "usable" patterns anymore, right? Not a huge deal: I don't have anything in production doing that, but I guess this concurrent stuff would mean I'd have to think about those sort of creative applications a little bit differently, right?

I believe you can use IDB transactions to achieve this.

> Edit: Also: How would MessageChannel ports work in a concurrent situation? I like to use MessageChannels to communicate with SWs from the client and I'm having trouble understanding how that would work once I dispatch the message from the window and give port2 to the SW... would the concurrent workers all "share" the port2 I sent to the SW?

When you use `navigator.serviceWorker.postMessage()` you would only see the message event in a single SW thread instance.  You would not be able to control which instance receives the postMessage.

If you want to communicate with all SW thread instances you could use BroadcastChannel.

If you want to communicate with a particular thread instance you would need to have the SW thread create the MessageChannel first and send it back to the window Client.  The SW thread could then keep itself alive with waitUntil() until the window messages back, etc.

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