On 1/12/13 7:46 AM, David Rajchenbach-Teller wrote:
As Firefox moves each day more to an asynchronous execution model, we
keep facing issues related to dependencies between tasks. Here are a few
examples:
1. component A can only be initialized one or more other components have
reached some state;
2. off main thread I/O should only be shutdown once all components that
can use it have reached a state in which they don't need it anymore;
3. private browsing should be displayed only once the state of the
session has been (asynchronously) saved.
In our codebase, most of the synchronization is done through the
observer service. While this service has proved very useful, it is also
quite limited. For instance, using this service to implement a
dependency for scenario 2. above is rather tricky.
So, perhaps it is time to start working on a library (or at least a
design guideline) that will simplify our work refactoring Firefox into
asynchronicity.
As a base for discussion, I have put together a small RFC based on
promises: https://wiki.mozilla.org/RFC/TaskDependencies
I love the nsIDependencyService API. Gated waiting on multiple async
events with timeouts is a *very* useful tool to have. I wish we had that
API in the tree! As it is, that API is more generic than a "dependency
service." But that's bikeshedding over naming.
While that API is generally useful, it only solves the "service
dependency" problem for services which are *always* initialized. If you
look at a more feature complete service initialization system such as
Upstart [1] or Service Management Facility [2], you'll find the current
proposal falls short in a number of areas, notably optional services.
If I were writing Gecko from scratch today and took the world view that
Gecko is an operating system, I would certainly be tempted to design
XPCOM/Gecko services as Upstart/SMF-like services. Each service would
list dependencies, runlevels, etc. Initializing a Gecko application
would involve bootstrapping into the service controller (the init/pid-1
process in *NIX speak) where you would request the start of a single
high-level "main" application/service (e.g. the "desktop-browser"
service for Firefox). The service controller would create a dependency
tree of all the required services (network, Places, etc) and proceed to
initialize them automagically.
Now, such a solution is probably not feasible in the short term. But, I
believe we would like to borrow some of its features.
Optional services come to mind. We currently have a number of features
that behave like services but aren't. Sync is definitely one. Addons
Manager /might/ be another. Their initialization is primarily controlled
by performing a Cu.import() where the side-effect is some
singleton/service is instantiated. This results in ugly hackiness like
lazy module getters and importers. This often results in inadvertent
misuse of a module by loading it too early. This results in memory bloat.
What would be really awesome is to capture service dependency metadata
and to declare services as optional. If nothing is relying on a service,
don't load it until it is needed! Sure, you'll probably want to pre-load
commonly used services as an optimization- nothing says you can't. The
real benefit is the ability to unload unused services, resulting in
memory recovery. Think Android and iOS and how they kill previously-used
applications during memory pressure. Don't need Addons Manager around
after installing that new add-on? Don't worry, it will be unloaded
automatically!
Would desktop Firefox benefit from such an advanced service management
system? I'm not sure. The real beneficiaries are mobile, especially
Firefox OS. Who knows, perhaps they invented something already!
I guess what I'm trying to say is: what problem are you trying to solve?
If it's for services as they exist in Gecko today, I think what you have
is a good start. But if you are looking to shed constraints from
decisions made 10+ years ago, you could certainly dream bigger.
[1] http://upstart.ubuntu.com/
[2] https://en.wikipedia.org/wiki/Service_Management_Facility
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
