Necko: better threading for IPC Necko

The problem

Our mechanism for delivering network data to content processes is suboptimal. Currently OnDataAvailable is routed through subprotocols of PNecko, which means that data must travel from the socket threads in the parent process to the main thread of the parent process before being serialized over the wire and sent to the main thread of the content process. Thus we must always absorb whatever latency exists between dispatch and running of events on the main thread of the parent process. Additionally, if the data is destined for a background thread in the content process (e.g. the HTML parser thread), we also unnecessarily absorb the latency on the main thread of the content process as well.

The solution

Phase 1

Bypass the main thread of the parent process.

We will use a PBackground subprotocol (PNeckoTransport?) with its endpoint on the main thread of the child process. Then we can use the PBackground thread to dispatch OnStartRequest/OnDataAvailable/OnStopRequest to the child process. This should work using the existing thread retargeting machinery, as long as there are no JS/etc nsIStreamListeners in the chain. sworkman expects that there will not be any nsIStreamListeners that cannot cooperate in the parent process (at least on B2G, e10s on desktop with addons may be another story).

Phase 2

(Optionally) bypass the main thread of the child process.

We create a new "Necko" thread in the content process and move the endpoint of PNeckoTransport from the main thread of the content process to this new Necko thread. From this thread we will make decisions about where to dispatch OnStartRequest/OnDataAvailable/OnStopRequest. We will have to queue ODA/etc until OnStartRequest has run on the main thread (and the opportunity for retargeting passes). For latency minimization we'll probably dispatch cancelable ODAs to the main thread before OnStartRequest runs, and if it chooses to retarget we will simply cancel them and redispatch them all to the desired thread. There's also some synchronization needed around ensuring that OnStopRequest does not run on the main thread before the background thread finishes consuming ODAs.

Unknowns

- How much performance win will this actually buy us and under what scenarios? Hopefully we can do measurements at each stage. - How to associate data coming over the background protocol with a given channel? - How often will we have nsIStreamListeners in the parent that won't cooperate with retargeting to the PBackground thread?

Diagram

[[1]]