1404409 - Creating e10s sockets blocks the content STS thread

Status: NEW

(Core :: WebRTC: Networking, enhancement, P3)

Description

[Byron Campen [:bwc]]

This sometimes takes more than a second on try, and I suspect it could be a cause of ICE-related intermittent failures.

There are a couple of things we might do about this:

One is async creation. This would eat errors that happen in socket creation, and might complicate lifecycle some.

Another is bulk creation of sockets and caching. This could waste resources, especially considering that we use select under the hood. Maybe we could mark the cached fds as idle. On the plus side, it could speed up connection establishment more than the async approach.

We might want to do both, since each carries its own benefits.

We also might want to record some telemetry on this, to see how big this problem is in the wild. Keep in mind that not only would we want to monitor how long |create| takes, we would want to time how long it took to make the initial gathering call (ie; how long it took to open all of our sockets).

Comment 1

[Byron Campen [:bwc]]

Also, I should point out that when we're creating lots of sockets, doing the work async would still lead to a huge speed-up since they wouldn't be created sequentially anymore.

Comment 2

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

Is the delay in response in our (mtransport) code, UDPSocket, UDPSocketParent (pbackground thread), or Master-side STS code?  I presume it goes like this: Content STS -> UDPSocketChild -> <ipc> -> UDPSocketParent (PBackground) -> Master STS and then back the other way -- or something like this.  I do hope it never touches MainThread in this sequence.