- Much of the add-on code runs in a separate process so cannot hang the UI for short periods of time.
- Has security benefits because we only need to provide what they need to add-ons in the add-on process.
- Gets around the problem with blocking file I/O.
- Even with add-on processes some part of the add-on will run in the main process (pagemods) and can hang the UI from there.
- Makes the APIs more complicated than they need to be.
- The e10s code would likely need to be maintained by us.
- Since E10S work is suspended no XPCOM e10sification is expected, which means we would have to do lots of message passing to do anything XPCOM related.
- Windows 8 Metro may not support additional processes.
- Performance and memory costs.
- Is e10s likely to come back? What design decision do we make based on the current positioning.
- Async APIs are better for forwards compatibility but more complex.
- Sticking with async APIs is complicated for add-on developers.
- Could diverge from the existing e10s APIs now to do our own more streamlined thing.
- Need better performance measurements for Jetpack.
- What are our main priorities and how does e10s fit into it?
- Do threads give us similar benefits without the same overhead?
- Performance-wise probably.
- Not stability-wise but maybe that isn't as important to us.
- Continue work on keeping the platform separated allowing for out of process / thread / worker support.
- Start taking some measurements the performance of the platform.
- Consider whether to start work on a prototype for running add-ons in their own thread.
- Mossop to start working on performance tests for the platform.
- Eddy to gather any final useful numbers from the OOP prototype.