<br><br><div class="gmail_quote">2009/5/21 Ulf Wiger <span dir="ltr"><<a href="mailto:ulf.wiger@erlang-consulting.com">ulf.wiger@erlang-consulting.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Alex Vazquez wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Anyway, just for curiosity, there would be any reason preventing some<br>
 kind of stop_phases scheme or it's just that nobody found it that necessary and/or had the time to do it?<br>
</blockquote>
<br></div>
Others may remember it differently, but this is my recollection.<br>
<br>
Back in 1996, when the AXD 301 project got started using the<br>
very first version of OTP, we fairly quickly ran into some<br>
problems. For sure, we had a very complex product to write*<br>
but we also had many more people than one would wish for in<br>
a first iteration of the system.<br>
<br>
* Piling the initial specifications on top of each other,<br>
they measured about 3 ft.<br>
<br>
One consequence was that we ended up with multiple teams<br>
working on the same application. To manage this, we split<br>
the application into sub-applications and wrote a build tool<br>
to merge them into one big .app file. This was the precursor<br>
to included applications.<br>
<br>
We also found that it was very difficult to manage the start<br>
sequence of applications with several processes and complex<br>
dependencies during initialization. After a period of writing<br>
messy code with processes casting to themselves and then<br>
rushing to get all the work done before someone thought to<br>
start using the APIs, we developed a form of start phases<br>
through use of environment variables (as I described previously)<br>
and a central start function.<br>
<br>
These two things eventually made it into OTP, in a slightly<br>
modified form. At the same time, AFAIR, the application<br>
behaviour was invented. By this time, OTP was used in several<br>
other projects, and it was reasoned that since the<br>
implementation meant that /any/ application could be made<br>
included just by adding it to the 'included_applications'<br>
attribute of another application**, it might not always<br>
be a good idea to call the original start functions etc.<br>
If the application had been designed under the assumption<br>
that it was a "top-level application", it might end up<br>
doing things that were not appropriate under the given<br>
circumstances.<br>
<br>
** This was actually another requirement from the AXD<br>
project, since we wanted to be able to include applications<br>
such as snmp, inets, etc. The reason for this was that we<br>
needed them to move together with other O&M components<br>
during failover and takeover. Many years later, we invented<br>
ways to handle the synchronized switchover without bundling<br>
everything into one app.<br>
<br>
Much later, we observed that it could also be quite problematic<br>
to stop these complex applications, and that some form of phased<br>
shutdown would sometimes be useful. That's when the prep_stop<br>
phase was invented. It was reasonable to give it similar<br>
semantics to the start, start phases, and stop callbacks.<br>
<br>
Does that satisfy your curiosity?<br>
</blockquote><div><br>I thank you the vast explanation, Ulf.<br><br>What sounds weird to me is the fact that start_phases are run for all included applications while prep_stop is only run for the primary application (Am i wrong in this assumption?). I was asking if this behaviour has some reason that i'm unaware of, but, again, thank you for the info.<br>
<br>Regards,<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
BR,<br>
Ulf W<div><div></div><div class="h5"><br>
-- <br>
Ulf Wiger<br>
CTO, Erlang Training & Consulting Ltd<br>
<a href="http://www.erlang-consulting.com" target="_blank">http://www.erlang-consulting.com</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Alejandro Vazquez Fente<br>