start phases

[Ulf Wiger (AL/EAB)]

I decided to implement a prototype hack of the application_controller.

The idea is that we should be able to extend the start phase concept 
significantly, and get cleaner (and perhaps faster) execution of complex 
system start sequences.

While you can still specify dependencies in the 'applications' attribute
as before, you can now also specify dependencies for each start phase,
like so:

{start_phases, [{Phase, Arg, [{run_before, [app() | phase()]} |
                              {run_after, [app() | phase()]}]}]}

The old way of specifying start_phases still works, and means 
no funny dependencies.

I imagine that one would make start phase specifications part of 
the application API, basically stating "after this phase, the 
following resources are available", etc.

The Application Controller will start applications and run start
phases concurrently as much as possible.(*)

To me, this is a fairly logical extension of the idea of application
dependencies. Since it's declarative, one could write a tool that 
reasons about the most efficient order in which to start things,
in order to achieve the optimal level of concurrency, while 
maintaining the safety guarantee. One could also analyse dependencies
off-line, visualize them, and warn about loops, to a much finer 
degree than today.

The whole thing is essentially a wild spin-off from AXD 301's start 
phase support.

As far as I know, the patch is backwards compatible, but applying the 
patch on an OTP R10B-2 was difficult to say the least, since it required 
some changes in the boot script. This means you have to apply some of the 
patches, re-build the boot scripts by hand, and then do some copying
by hand, before you can apply the last patches and run the system. (**)

I built it, but don't really know what to do with it now.
Does anyone feel like testing it? If so, let me know.

/Uffe


(*) One could also speculate that instead of the 'risky_shell' flag,
one might specify after which start phase(s) the shell should be made 
available. The shell process could then simply call
application_coordinator:await_start_phase(App, Phase), which returns
'ok' when all is set.

(**) This is OT, but the make script uses a pre-built script, which was 
made using a special emulator. It is not re-built - ever! It's just 
copied into the final build as the default script.