852763 - Allow sending/receiving IPDL messages to non-main threads on a per-msg basis

Status: RESOLVED WONTFIX

(Core :: IPC, defect)

Description

[Jason Duell]

Right now data coming in off the network has to do this event traffic in e10s:

  socket transport thread -> main thread -> IPDL thread
   ---> IPC to child -->
  IPDL thread -> main thread  -> HTML parser or imglib thread

If we can allow IPDL send/recv off main thread (and fix bug 791750), we can eliminate the two useless hops to the main thread event loop for every OnDataAvailable call.

Comment 1

[Josh Matthews [:jdm]]

As far as I know, this is already possible (see bug 627635 comment 82 and the next few ones from Chris).

Comment 2

[Jason Duell]

Thanks for the pointer, jdm.  This is good news.  Necko may need some additional stuff here though, as we don't actually want *all* messages for PHttp to go to the non-main thread, we only OnDataAvailable to do that.  (Otherwise we'll just wind up adding extra hops to the non-main thread, since OnStart and possibly OnStop need to go to the main thread.)  And in an ideal world, we'd actually want to be able to tell IPDL during OnStart whether or not this particular channel's OnDataAvailable should go to the main thread or not (some channels will have to do main-thread delivery for ODA). It sounds like we can probably add some IPDL syntax to make all that possible.

I'm blocking this on bug 791750 as we may not know the exact API we'll want until that's finished.

It would be nice to know how much of a win all this work would be, so we could tell if it's worth it or not.  But I don't have a good idea of how to measure it--some of the benefit is less child process main thread event jank.

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Comment 1 is correct.  We use that feature extensively.

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Oh, sorry, I replied to the wrong message.  IPDL channels are strongly single-threaded (not necessarily main thread) and there's no way to change that.

Comment 5

[Jason Duell]

> there's no way to change that.

At the risk of contradicting cjones (hazardous business, that) I find this hard to believe.  The code might be hard to change, possibly.  Maybe not worth it.  But we'll be doing pointless extra hops to the main thread for incoming network data w/o this changed.  Seems worth investigating at least.

I don't know whether IPDL queues incoming messages on the IPDL thread, or dispatches them to the target thread (to be queued like any other event).  I assume the latter.  In that case we'd need to tell the IPDL thread that for certain channels it would have to queue incoming messages after delivering the 1st (OnStart), until it hears back from that thread whether to continue delivering to the same thread, or a different one, for the rest of the IPDL channel's lifetime.

Am I way off base here? Doesn't sound like rocket science.

Comment 6

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Everything from high-level IPDL semantics to the low-level implementation of IPC has been strongly single-threaded from the start.  If you need to shovel data around to threads other than the one the channel is bound to, then do it at the user level.

I know what you're describing sounds simple, but it's staggeringly complex implementation-wise :).  Hate to be a wet blanket here.

Comment 7

[Benjamin Smedberg]

Or you can open an entirely separate channel/IPDL session with that other thread...