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

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Justin Lebar (not reading bugmail)]

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...

Comment 1

[Justin Lebar (not reading bugmail)]

Attachment: Part 1: Add AsyncChannel::{Pause,Unpause}()

Comment 2

[Justin Lebar (not reading bugmail)]

Attachment: Part 2: Add ContentParent::{Pause,Unpause}Messages().

Comment 3

[Justin Lebar (not reading bugmail)]

Attachment: 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".

Comment 4

[Justin Lebar (not reading bugmail)]

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?

Comment 5

[Johnny Stenback (: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.

Comment 6

[Justin Lebar (not reading bugmail)]

I think we can wontfix this; it looks like what we have in bug 870480 was the missing piece here.