1284369 - consider throttling runnable dispatch from IPC actors

Status: NEW

(Core :: IPC, defect, P3)

Description

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

Bill is working on changes to use nsIEventTarget on a per-actor basis.  This should wait for that work.