Open Bug 1284369 Opened 4 years ago Updated 2 years ago

consider throttling runnable dispatch from IPC actors

Categories

(Core :: IPC, defect, P3)

defect

Tracking

()

Tracking Status
firefox50 --- affected

People

(Reporter: bkelly, Unassigned)

References

(Blocks 2 open bugs)

Details

Recently I was thinking about how to solve problems like bug 1208840.  In these cases we have a large number of IDB requests firing IPC traffic from the parent to child to signal some event.  This swamps the main thread with runnables before events are even fired on the target thread.  (Indeed, in the case of bug 1208840 there weren't even any event handlers registered.)

Clearly the work to bucket and priporitize runnables would help with this a lot, but we could also just be smarter about not swamping the event queue from a single source.

One idea I had was to do this by default in every IPC actor:

1) Make the runnables that fire from the IPC connection thread to the target thread dispatch back to the IPC connection thread after they are done.  This allows us to track how many outstanding runnables the actor has.
2) If we hit some limit, like 10, on the number of outstanding runnables, then start queuing the runnables in the actor on the IPC thread.
3) When runnables complete on the target thread then drain the IPC thread queued runnables.

I say to queue them in the actor here, but really there are a few different approaches:

- Queue in each individual actor
- Queue in each actor, and child actors contribute to their owning parent actor's limit
- Queue in only the actors that are direct children of PContent or PBackground, and all children contribute to that top level queue

The goal is to basically throttle an IDB connection and allow things like compositing to still run.  We would want to maintain ordering within the IDB set of actors, however.

I haven't tried this yet, but thought I would just write it down in case someone wants to experiment with it.  The test case in bug 1208840 would be a great one to use here.
You either have to not re-order messages (i.e. queue everything) or deal with all the fallout from that.  Some actors are probably reorderable without much trouble but others definitely aren't.
See Also: → 1300118
I think there is a simple solution that would get us some immediate benefit.  Basically we can throttle all IPC with a single TaskQueue.  This should prevent actors from killing js, style, paint, etc responsiveness.
Assignee: nobody → bkelly
Status: NEW → ASSIGNED
Blocks: QuantumDOM
Bill is working on changes to use nsIEventTarget on a per-actor basis.  This should wait for that work.
Assignee: bkelly → nobody
Status: ASSIGNED → NEW
Depends on: 1312960
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.