Throttle or pause messages to and/or from processes when a call is incoming

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
6 years ago
6 years ago

People

(Reporter: justin.lebar+bug, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
This is one (somewhat heavy-handed) approach we've considered for bug 847592.  At the very least, if this approach solves our problem, it would help us understand what's going wrong.

I have a wip patch for this that seems to work...
(Reporter)

Comment 1

6 years ago
Created attachment 746232 [details] [diff] [review]
Part 1: Add AsyncChannel::{Pause,Unpause}()
(Reporter)

Comment 2

6 years ago
Created attachment 746233 [details] [diff] [review]
Part 2: Add ContentParent::{Pause,Unpause}Messages().
(Reporter)

Comment 3

6 years ago
Created attachment 746234 [details] [diff] [review]
Part 3 (WIP): Pause messages to and from non-high-priority processes upon receiving a call.

This patch is based on a previous patch where I changed CPU priorities, so the language still speaks about lowering a process's CPU priority.  Read that as "stop sending and receiving messages from it".
(Reporter)

Comment 4

6 years ago
Do we want to do this?

It feels to me like this cure may be worse than the disease, because it will cause the phone to completely freeze for a second or two until we handle the call, but it probably would fix bug 847592 in many cases.  We're still not protected from the case when the browser process spins the CPU e.g. in a JS loop.  With a simple testcase that spins the CPU (http://bit.ly/mozloop), I can get a ~3s delay.  I suspect that if I was doing graphics-intensive stuff which put a burden on the main-process compositor, I could get a longer delay.

I'm not sure who should be making this UX call, particularly in light of the time-frame we have (I don't even know what the precise timeframe is, to be honest).

jst, can you please advise as to who decides whether this is an acceptable solution?
Flags: needinfo?(jst)
I think this decision ultimately comes down to a combination of sicking, bent, and release drivers as to whether we want to take the risk in making a change like this at this late a time. Personally I'd be ok with taking this change, but I'm not exactly an expert in this field.
Flags: needinfo?(jst)
(Reporter)

Comment 6

6 years ago
I think we can wontfix this; it looks like what we have in bug 870480 was the missing piece here.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.