1956967 - [meta] Long runnables on the parent process main thread can delay the delivery of the server's response for the initial app link URL

Status: NEW

(Core :: Networking: HTTP, task, P2)

Description

[Markus Stange [:mstange]]

This bug is about delays when receiving data from the server. See bug 1956964 for the "initiate request" equivalent to this bug.

When we load the initial page in the "applink startup" scenario (see bug 1945906), once the server sends us back the headers and HTML bytes, we want to get those bytes to the HTML parser in the content process as quickly as possible, so that we can start doing useful work.

However, getting the bytes to that place currently involves many runnables on the parent process main thread. This can cause arbitrary delays if there is any other work happening on the parent process main thread.

Here's an example profile: https://share.firefox.dev/4hTye38
This profile shows a 112ms delay between responseEnd and getting the bytes to the HTML5 Parser thread in the content process.

These 112ms are due to delays of the following runnables:

1. nsPipeInputStream AsyncWait Callback, notifying the main thread about the received bytes
2. a brief dance through the content process for DocumentChannel + RedirectToRealChannel, which involves creating a new background channel from the content process and pairing it up with the existing channel. This dance includes any delays from getting things to run on the IPC I/O threads, IPDL Background threads, and content process socket thread + main thread
3. net::ContinueAsyncOpenRunnable, i.e. waiting to call LinkBackgroundChannel on the parent process main thread, linking the "document channel" and the "real channel"
4. WaitForBgParent MozPromise resolution runnable, another round-trip from the main thread to itself. This calls nsHttpChannel::Resume.
5. nsPipeInputStream AsyncWait Callback, another main thread to main thread round-trip. This runs nsHttpChannel::OnDataAvailable on the parent process main thread

In the linked profile, the delay of runnables 1 and 3 contribute most of the total delay, but any one of these hops could get unlucky and causes delays.

---

This bug can be considered resolved once you can put an arbitrarily long task on the parent process main thread without causing a delay between receiving the server response on the parent process socket thread and parsing the bytes on the content process HTML5 parser thread.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

May be S2. Note: meta, so not adding to -new

Comment 2

[Andrew Creskey [:acreskey]]

I believe bug 1952237 would resolve item 5, retargetting HttpChannelParent::OnDataAvailable off-main-thread

(In reply to Markus Stange [:mstange] from comment #0)

5. nsPipeInputStream AsyncWait Callback, another main thread to main thread round-trip. This runs nsHttpChannel::OnDataAvailable on the parent process main thread

And actually I have an old patch that I believe will resolve item 4, https://phabricator.services.mozilla.com/D146481
Let me rebase and evaluate and land that.

4. WaitForBgParent MozPromise resolution runnable, another round-trip from the main thread to itself. This calls nsHttpChannel::Resume.