Currently there is work happening to move the GPU compositor into its own process. This is to improve stability by allowing us to recover from gfx crashes. Perhaps we should consider doing the same thing for network operations. We periodically have crashes due to anti-virus and other external actors modifying our network stack. In addition, new protocols are a potential surface area for crashes and attacks. Running network code in a separate process would help mitigate crashes and attacks. As a side effect, it would also reduce contention on the parent process main thread between network requests and other work during page load.

FWIW, this post mentions chrome is moving to a sandboxed network process soon: https://medium.com/@justin.schuh/securing-browsers-through-isolation-versus-mitigation-15f0baced2c2#.o8sn6z5ms

A similar idea has been brought up when WebRTC and Necko folks talked at all hands meeting in Hawaii. Another benefit would be all other processes would no longer need network access for their sandbox, as this would be the only process with network access. One of the big concerns especially for WebRTC is what are the costs going to be for sending all the real time data across several processes. But we are doing something similar with e10s already, so hopefully this would not much worse in terms of performance.

(In reply to Ben Kelly [not reviewing due to deadline][:bkelly] from comment #1) > FWIW, this post mentions chrome is moving to a sandboxed network process > soon: > > https://medium.com/@justin.schuh/securing-browsers-through-isolation-versus- > mitigation-15f0baced2c2#.o8sn6z5ms Also, it seems safari has had a dedicated network process for a while now.

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

This doesn't block bug 1359559 -- that covers locking down the content process sandbox, a network process is about removing attack surface from the parent process.

Please note that moving network code to a separate process will mean not receiving Telemetry from that code until the plumbing from bug 1486033 is in place.

For reference, the changeset on larch we stopped the work at, having patches that were both in progress or r+'ed but not landed on larch, is 94a22fd022b9.

I'm hoping this will also benefit Thunderbird, currently typing stalls in composing, when main thread checks email servers for new mail.

(In reply to Dennis Jakobsen from comment #9) > I'm hoping this will also benefit Thunderbird, currently typing stalls in > composing, when main thread checks email servers for new mail. Is there a reason you think THunderbird will benefit? Imap in Thunderbird already has it's own, non-blocking (iirc) threads. pop is main thread/doesn't have its own threads for architectural reasons. Perhaps the tcp can be offloaded there, but I doubt tcp activity related to pop is a major contributor to what you are seeing in Thunderbird

(In reply to Wayne Mery (:wsmwk) from comment #10) > (In reply to Dennis Jakobsen from comment #9) > > I'm hoping this will also benefit Thunderbird, currently typing stalls in > > composing, when main thread checks email servers for new mail. > > Is there a reason you think THunderbird will benefit? > > Imap in Thunderbird already has it's own, non-blocking (iirc) threads. > > pop is main thread/doesn't have its own threads for architectural reasons. > Perhaps the tcp can be offloaded there, but I doubt tcp activity related to > pop is a major contributor to what you are seeing in Thunderbird I have 5 accounts, mixed pop/imap. I'll try and disable auto checking on the pop accounts and confirm what you are saying. But it's unbearable writing emails when the caret is lagging 5 chars behind what you are typing.

Or maybe i should just request Thunderbird uses a separate thread for the compose window, then they can do all the stuff they want in the main window/thread.