On Thursday, May 7, 2015 at 2:51:39 PM UTC+2, Ehsan Akhgari wrote: > 1. Because service workers run on their own thread, they add some > latency for determining what to do for each network request. Therefore > running them for all network requests across the entire browser is > probably impractical.
That latency will be there either way with E10S. We attempted to decentralize the decision making for Fennec back when it was using E10S - that didn't work well, lots of complexity but also latencies were introduced due to state syncing, and the memory usage exploded. So an E10S compatible implementation would still have all the decisions being made in one process - and content processes using synchronous messaging to contact it. Still, I'm not entirely sure what the advantage of a ServiceWorker would be here. Would that make our processing merely delay the network request but not everything else that happens on the UI thread? That might offload the UI thread a bit, but I can imagine that the API would require significant changes in order to work for us. I see that there is Request.context but I cannot immediately see whether it is possible to deduce the frame structure somehow (i.e. which document made this request, what is the URL of its parent frame etc). Plus of course the issues already mentioned - running a separate ServiceWorker for each tab sounds wasteful. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
