621702 - Integrate PageMod API with e10s

Status: RESOLVED WONTFIX

(Add-on SDK Graveyard :: General, defect)

Comment 1

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

I have created this document describing problems and potential solutions:

https://gist.github.com/765140

I'll keep updating, while progressing with this task.

Comment 2

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

# E10S Integration #

## Problems ##

- **Identity**
  Currently code uses `==` operator to identify references to the same instance
  and `instanceof` to identify type of an instance. Obvious solution to avoid
  duplicate wrappers _(that will lead to incorrect `==`)_ is to have unique id
  on each instance and registry of wrapped instances (wrapper can be removed
  from it once instance is destroyed).

- **Callbacks**
  In variety of APIs users can set callbacks which are called with an argument
  that is an instance of certain class (Worker or Tab for example). Such
  callbacks will have to be called with a wrappers implementing same api as
  original object (But original objects are wrappers of dom elements and
  wrapping them once again doesn't really feels right).

- **Mixed chrome / addon modules**
  Currently code that can run in addon or chrome process is pretty much mixed
  together in the same module, identifying principals and separating them into
  separate modules may be a very good idea.

- **DOM**
  Many modules wrap some DOM elements, set event listeners on events and pass
  them around just for a few properties. Obviously listeners can't be in the
  different process neither they can call functions from the other process if
  they pass dom element to it. (Can we have an API in a functional style for
  registering listeners that will read some properties and then call callback
  on the other process with the values of that properties ?).

- **createHandle**
  A handle can be used as property storage that are not transmitted across the
  process boundary, which is useful to store callbacks that have to be triggered
  form another process. Unfortunately all the functions properties are converted
  to an `undefined` and object properties to an empty objects `{}`. This would
  make things simple, but can be replaced by having a registry on both sides of
  the process.

- **Drawing a line**
  It's very hard to define where exactly separation should take a place.
  Adapters / wrappers can be either created at the low `XPCOM` level, in which
  case low level APIs will have to be simplified / changed (no dom will have to
  be exposed) and that will cause large changes in the implementation of high
  level modules or wrappers can be created for the high level APIs in which case
  lot's of code get duplicated three times and most of it ends up running in the
  chrome process.

- **Registries**
  It seems like any approach (other then promise based ?) will require some
  global registry of everything that is passed across processes, without
  [Ephemeron tables] all the gc work will have to be performed manually, which
  is a lot of work and may cause cause memory leaks (Callbacks for instance
  don't have destroy methods, when should we remove them from registry? Non
  routed handles, would have been handy but they don't seem to work).

## Random ideas / Prior art ##

- Having functional style wrappers for all the XPCOM APIs we relay on.
- [Proxy] based cross process messaging.
- [Communicating Event-Loop Concurrency and Distribution]
- [Communicating asynchronously with remote objects using promises]

[Ephemeron tables]:http://en.wikipedia.org/wiki/Ephemeron
[Proxy]:http://wiki.ecmascript.org/doku.php?id=harmony:proxies
[Communicating Event-Loop Concurrency and Distribution]:http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
[Communicating asynchronously with remote objects using promises]:https://github.com/kriskowal/q-comm/tree/master/lib

Comment 3

[Myk Melez [:myk] [@mykmelez]]

Alex suggested it might be helpful to use Etherpad to collaborate on identifying and resolving these issues, so I copied the current contents of the gist to this Etherpad:

http://etherpad.mozilla.com:9000/jetpack-e10s-issues

Comment 4

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Comment for bug triage: Since E10S is no longer planned for 1.0 milestone for this one should be post 1.0

Comment 5

[Myk Melez [:myk] [@mykmelez]]

Indeed, and we should close it in the meantime, since our next effort to integrate e10s may well require a different set of bugs than the current module-specific bugs.