(In reply to Tarek Ziadé (:tarek) from comment #1)
the pattern is:
- ask all processes something, under a specific uuid
- collect all results for that uuid in a singleton (with an IPC timeout to deal with unresponsive processes)
- resolve a promise with the aggregated results
(basically, Chromeutils.RequestPerformanceMetrics() pattern, but for any ipdl call that is broadcasted)
The memory reporter also has this general shape: send a request to every process and collect the results, with timeouts, and an identifier to distinguish requests. (It also has, or at least used to have when I was working on it, a limit on the number of processes with outstanding requests at once; that was important on B2G but might not matter in this case.) The profiler is also roughly similar, but has its own top-level protocol and dedicated threads so it can work even if the main thread is stuck or deadlocked.
Anyway, this is a harder problem than it seems. For all of these things that every (or almost every) child process uses, every process type has to declare the IPDL methods and implement them separately; I think we've spent several hours by now in IPC status meetings just discussing how to design a solution to this, and we still don't have a good answer. (Note that PGPU and PRDD have the parent/child roles reversed, so we can't even factor everything out into a common managed actor.) There's also the problem of iterating all of the relevant actor objects to send the messages, given that they're all distinct classes and have nothing in common besides
IToplevelProtocol (which is subclassed by every actor, parent or child, that's at the root of the tree associated with any channel, not just the process's main actor).
Something that might help here is bug 1512990: the process actors (
PContent, etc.) are all devirtualized, so the concrete classes can inherit implementations for
Recv methods. If all of the process “parent” actors (
GPUChild, etc.) had a common superclass (common to just them, not more general like
IToplevelProtocol), then that class could maintain a global list of instances… but it would still need virtual method boilerplate to call the concrete classes'
Send methods, unless that were handled by another level of superclass templated on the concrete class type to be able to
static_cast itself and call the methods. Something along those lines.
(That still doesn't help with IPDL declarations; there are some ideas about letting protocols inherit/include other protocols, but nothing concrete. But copying/pasting those isn't the worst part of this.)
As for file locations, generally tools that apply to all of IPC and not just content processes go into
ipc/glue (which should probably be renamed at some point, because it's no longer only glue code).