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

Just to clarify my position, I think there is an architectural advantage for pages with many simultaneous loads like this benchmark.  The ~20% improvement from co-locating the SW in the same process as the page may not exist for more typical page loads.  We should probably make a similar benchmark for ~20 images or something.

Also, I think we need to weigh this benefit against the compat issues.  It did not take me long to find sites that broke with the "create a new thread for every event" build I hacked together.  People are definitely expecting to use global state and postMessage() within the context of a `waitUntil()` holding the worker alive.  I think we need a better proposal about how to solve this issue.

> thread pool does help with the "blocking worker" case

After looking at this for a while I really don't think we should aim for a thread pool to support the blocking worker case.  I'd rather expose explicit APIs so developers can offload heavy CPU load into a separate thread.  That way devs don't have to contort their code to try to trigger the "magic parallelism heuristic" different browser might implement.  For example, think of how people try to optimize for the v8 jit in ways that may not make sense for all browsers.  Lets steer clear of that if we can.

> By removing this restriction we should be able to optimize for the two scenarios above as well as allowing push and background sync events that can be handled in a timely and concurrent fashion in the background.

I'm open to the idea of a separate thread instance for these cases in order to support firing the events when the browser is not running.  In my mind this is less of a perf issue, though, and more of an OS integration issue.

Again, though, we need to think about how a SW might communicate with a window from a push event using postMessage().  For example, a push/notification SW instance might want to postMessage a Client in order to trigger a SPA route update, etc.  If there is any kind of communication back to the SW after this completes, then these sites will break.

If I could go back in time I'd probably remove the `ServiceWorker.postMessage()` method.  I can't think of any valid use case for initiating a postMessage from the window to a service worker.  Anything you can do in the service worker (Cache API, etc) you can do from the window.

In contrast, a ServiceWorker should have `Client.postMessage()` available since that supports many real use cases.  If it needs a response message back it could then pass a MessageChannel in its message to the Client.

Anyway, I believe in Firefox we are going to pursue our "FF multi-e10s" approach for now.  Its the most web compatible even if it does regress performance.  We can then consider optimizations such as co-locating the worker thread in the document process again in the future if we can solve this spec issue.

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