Closed Bug 1413606 Opened 2 years ago Closed 2 years ago

Land Client actor scaffolding

Categories

(Core :: DOM: Core & HTML, enhancement)

enhancement
Not set

Tracking

()

RESOLVED FIXED
mozilla58
Tracking Status
firefox58 --- fixed

People

(Reporter: bkelly, Assigned: bkelly)

References

Details

Attachments

(2 files)

This forks some of the initial IPC actor scaffolding from bug 1293277.  Some thoughts I wrote over there about this code, copied here for convenience:

This sizeable patch stubs out the various IPC actors.  There are some long living actors that form this structure:

* PBackground
  * PClientManager
    * PClientSource
    * PClientHandle

Each of these corresponds to an outer owning object.

* ClientManager is going to be a ref-counted per-thread singleton.  It will be a factory for creating ClientSource and ClientHandle objects.  It will also provide methods for performing operations to query Clients, navigate Clients, etc.
* ClientSource will be an RAII style object that each window/worker owns.  While it exists the global is considered alive.  It should be destroyed when the global is destroyed.  This is how we map globals to the Client concept.
* ClientHandle is a way to attach to an existing Client.  It is a ref-counted object.  When creating a ClientHandle the ClientManager will match up the provided ClientInfo to a corresponding ClientSource.  Messages like postMessage(), focus(), etc will then be forwarded to the correct ClientSource.  If the ClientSource goes away, then these operations will simply reject.  The ClientHandle can out live the ClientSource.

In addition to this basic structure, there are a number of "operation" type actors here.  I wrote all of this before the async RPC style ipdl support was added.  I considered going back and rewriting this stuff, but I opted not to for now.  The async RPC support requires slightly different MozPromise usage than I am using here.  It also has some subtle differences on life cycle management that I would have to hunt down.  Given that this bug is way behind I decided not to tackle that for now.

The operations are:

* PBackground
  * PClientManager
    * PClientManagerOp: various child-to-parent operations
    * PClientNavigateOp: A parent-to-child operation.
  * PClientSource
    * PClientSourceOp: various parent-to-child operations
  * PClientHandle
    * PClientHandleOp: various child-to-parent operations

* PContent
  * PClientOpenWindowOp: A parent-to-child operation for opening a new window cross-process with an async return that provides corresponding ClientInfo.

For the most part this patch is just boilerplate.  The actors and types don't have any useful information in them.  I thought getting this out of the way in a separate patch would make it easier to read later patches where I add functionality.
Pushed by bkelly@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/6ecdbbd7ed75
P1 Add ClientThing base class. r=baku
https://hg.mozilla.org/integration/mozilla-inbound/rev/fba8efa8ffe2
P2 Add IPC actor structure and boilerplate. r=baku
https://hg.mozilla.org/mozilla-central/rev/6ecdbbd7ed75
https://hg.mozilla.org/mozilla-central/rev/fba8efa8ffe2
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
Depends on: 1415829
No longer depends on: 1415829
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.