1026090 - WebRTC LoadMonitor opens /proc/stat

Status: NEW

(Core :: WebRTC, defect, P4)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

From content/media/webrtc/LoadMonitor.cpp:

    373   procStatFile->InitWithPath(NS_LITERAL_STRING("/proc/stat"));

This is code we control, so it should be doable to have the parent open the file and return the parsed information.

Also… we seem to have two "Sys Load Info" threads in the same process, each independently opening and reading /proc/stat once per second.  Since I'm using http://mozilla.github.io/webrtc-landing/pc_test.html I'd guess there's one per endpoint.  This may or may not be improvable as a side-effect of this bug.

Comment 1

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

Two+ LoadMonitor threads is a bug I fixed at the end of last week - we now have a singleton for the LoadMonitor; make sure you have that patch.  (Bug 1022235)

Sure, on B2G it would make sense to have the LoadMonitor in the parent (ditto E10S)

Comment 2

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Sorry for the bugspam; filter on 086f2ac3-ac15-4299-889b-009181af5029.

Comment 3

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Sorry for the bugspam; filter on 086f2ac3-ac15-4299-889b-009181af5029.

Comment 4

[Jim Mathies [:jimm]]

Jesup, is this a valid bug in desktop sandboxing?

Comment 5

[Gian-Carlo Pascutto [:gcp]]

I'm fairly sure LoadMonitor still sits at the content side.

Comment 6

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

(In reply to Gian-Carlo Pascutto [:gcp] from comment #5)
> I'm fairly sure LoadMonitor still sits at the content side.

Yes.  We should look to move the load monitor to the Master process and periodically update the children, especially as we move towards multi-content-processes.  It's not low-latency.

Comment 7

[Bulk Bug Changes for mreavy's org]

Mass change P3->P4 to align with new Mozilla triage process.