I'm willing to admit that ServiceWorker was something of a wild idea. But yes, the original idea was to let a thread perform all interceptions. It was my hope that we could extend ServiceWorker to have one shared KindOfServiceWorker per process, which would avoid most of the waste.
Now, if ServiceWorker is not the right API, what would be? On 21/05/15 15:19, t...@adblockplus.org wrote: > 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 > -- David Rajchenbach-Teller, PhD Performance Team, Mozilla _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
