aboutsummaryrefslogtreecommitdiffstats
path: root/system/doc/design_principles
diff options
context:
space:
mode:
Diffstat (limited to 'system/doc/design_principles')
-rw-r--r--system/doc/design_principles/Makefile2
-rw-r--r--system/doc/design_principles/appup_cookbook.xml61
-rw-r--r--system/doc/design_principles/make.dep31
-rw-r--r--system/doc/design_principles/release_handling.xml52
-rw-r--r--system/doc/design_principles/spec_proc.xml48
-rw-r--r--system/doc/design_principles/sup_princ.xml21
6 files changed, 145 insertions, 70 deletions
diff --git a/system/doc/design_principles/Makefile b/system/doc/design_principles/Makefile
index b3fe136644..ae951ba8d4 100644
--- a/system/doc/design_principles/Makefile
+++ b/system/doc/design_principles/Makefile
@@ -79,6 +79,8 @@ DVIPS_FLAGS +=
# ----------------------------------------------------
# Targets
# ----------------------------------------------------
+_create_dirs := $(shell mkdir -p $(HTMLDIR))
+
$(HTMLDIR)/%.gif: %.gif
$(INSTALL_DATA) $< $@
diff --git a/system/doc/design_principles/appup_cookbook.xml b/system/doc/design_principles/appup_cookbook.xml
index bc61578953..798b23d847 100644
--- a/system/doc/design_principles/appup_cookbook.xml
+++ b/system/doc/design_principles/appup_cookbook.xml
@@ -4,7 +4,7 @@
<chapter>
<header>
<copyright>
- <year>2003</year><year>2009</year>
+ <year>2003</year><year>2011</year>
<holder>Ericsson AB. All Rights Reserved.</holder>
</copyright>
<legalnotice>
@@ -603,25 +603,60 @@ code_change(_OldVsn, State, port) ->
</section>
<section>
- <title>Emulator Restart</title>
- <p>If the emulator can or should be restarted, the very simple
- <c>.relup</c> file can be created manually:</p>
+ <title>Emulator Restart and Upgrade</title>
+ <p>There are two upgrade instructions that will restart the emulator:</p>
+ <taglist>
+ <tag><c>restart_new_emulator</c></tag>
+ <item>Intended for when erts, kernel, stdlib or sasl is
+ upgraded. It is automatically added when the relup file is
+ generated by <c>systools:make_relup/3,4</c>. It is executed
+ before all other upgrade instructions. See
+ <seealso marker="release_handling#restart_new_emulator_instr">Release
+ Handling</seealso> for more information about this
+ instruction.</item>
+ <tag><c>restart_emulator</c></tag>
+ <item>Used when a restart of the emulator is required after all
+ other upgrade instructions are executed. See
+ <seealso marker="release_handling#restart_emulator_instr">Release
+ Handling</seealso> for more information about this
+ instruction.</item>
+ </taglist>
+
+ <p>If an emulator restart is necessary and no upgrade instructions
+ are needed, i.e. if the restart itself is enough for the
+ upgraded applications to start running the new versions, a very
+ simple <c>.relup</c> file can be created manually:</p>
<code type="none">
{"B",
[{"A",
[],
- [restart_new_emulator]}],
+ [restart_emulator]}],
[{"A",
[],
- [restart_new_emulator]}]
+ [restart_emulator]}]
}.</code>
- <p>This way, the release handler framework with automatic packing
- and unpacking of release packages, automatic path updates etc. can
- be used without having to specify <c>.appup</c> files.</p>
- <p>If some transformation of persistent data, for example database
- contents, needs to be done before installing the new release
- version, instructions for this can be added to the <c>.relup</c>
- file as well.</p>
+ <p>In this case, the release handler framework with automatic
+ packing and unpacking of release packages, automatic path
+ updates etc. can be used without having to specify <c>.appup</c>
+ files.</p>
+ </section>
+
+ <section>
+ <title>Emulator Upgrade from pre OTP R15</title>
+ <p>From OTP R15, an emulator upgrade is performed by restarting
+ the emulator with new versions of the core applications
+ (<c>kernel</c>, <c>stdlib</c> and <c>sasl</c>) before loading code
+ and running upgrade instruction for other applications. For this
+ to work, the release to upgrade from must includes OTP R15 or
+ later. For the case where the release to upgrade from includes an
+ earlier emulator version, <c>systools:make_relup</c> will create a
+ backwards compatible relup file. This means that all upgrade
+ instructions will be executed before the emulator is
+ restarted. The new application code will therefore be loaded into
+ the old emulator. If the new code is compiled with the new
+ emulator, there might be cases where the beam format has changed
+ and beam files can not be loaded. To overcome this problem, the
+ new code should be compiled with the old emulator.</p>
</section>
</chapter>
diff --git a/system/doc/design_principles/make.dep b/system/doc/design_principles/make.dep
deleted file mode 100644
index 05dd2333fb..0000000000
--- a/system/doc/design_principles/make.dep
+++ /dev/null
@@ -1,31 +0,0 @@
-# ----------------------------------------------------
-# >>>> Do not edit this file <<<<
-# This file was automaticly generated by
-# /home/gandalf/otp/bin/docdepend
-# ----------------------------------------------------
-
-
-# ----------------------------------------------------
-# TeX files that the DVI file depend on
-# ----------------------------------------------------
-
-book.dvi: applications.tex appup_cookbook.tex book.tex \
- des_princ.tex distributed_applications.tex \
- events.tex fsm.tex gen_server_concepts.tex \
- included_applications.tex part.tex release_handling.tex \
- release_structure.tex spec_proc.tex sup_princ.tex
-
-# ----------------------------------------------------
-# Pictures that the DVI file depend on
-# ----------------------------------------------------
-
-book.dvi: sup6.ps
-
-book.dvi: dist1.ps dist2.ps dist3.ps dist4.ps dist5.ps
-
-book.dvi: clientserver.ps
-
-book.dvi: inclappls.ps
-
-book.dvi: sup4.ps sup5.ps
-
diff --git a/system/doc/design_principles/release_handling.xml b/system/doc/design_principles/release_handling.xml
index 1d62c242c0..8ed36f3c56 100644
--- a/system/doc/design_principles/release_handling.xml
+++ b/system/doc/design_principles/release_handling.xml
@@ -4,7 +4,7 @@
<chapter>
<header>
<copyright>
- <year>2003</year><year>2009</year>
+ <year>2003</year><year>2011</year>
<holder>Ericsson AB. All Rights Reserved.</holder>
</copyright>
<legalnotice>
@@ -313,18 +313,35 @@
</section>
<section>
+ <marker id="restart_new_emulator_instr"></marker>
<title>restart_new_emulator (low-level)</title>
<p>This instruction is used when changing to a new emulator
- version, or if a system reboot is needed for some other reason.
- Requires that the system is started with heart beat
+ version, or when any of the core applications kernel, stdlib
+ or sasl is upgraded. If a system reboot is needed for some
+ other reason, the <c>restart_emulator</c> instruction should
+ be used instead.</p>
+ <p>Requires that the system is started with heart beat
monitoring, see <c>erl(1)</c> and <c>heart(3)</c>.</p>
- <p>When the release handler encounters the instruction, it shuts
- down the current emulator by calling <c>init:reboot()</c>, see
+ <p>The <c>restart_new_emulator</c> instruction shall always be
+ the very first instruction in a relup. If the relup is
+ generated by <c>systools:make_relup/3,4</c> this is
+ automatically ensured.</p>
+ <p>When the release handler encounters the instruction, it first
+ generates a temporary boot file, which starts the new versions
+ of the emulator and the core applications. Then it shuts down
+ the current emulator by calling <c>init:reboot()</c>, see
<c>init(3)</c>. All processes are terminated gracefully and
the system can then be rebooted by the heart program, using
- the new release version. This new version must still be made
- permanent when the new emulator is up and running. Otherwise,
- the old version is used in case of a new system reboot.</p>
+ the temporary boot file. After the reboot, the rest of the
+ relup instructions are executed. This is done as a part of the
+ boot script.</p>
+ <p>An info report is written when the upgrade is completed. To
+ programatically find out if the upgrade is complete,
+ call <c>release_handler:which_releases/0</c> and check if the
+ expected release has status <c>current</c>.</p>
+ <p>The new version must be made permanent when the new emulator
+ is up and running. Otherwise, the old version will be used in
+ case of a new system reboot.</p>
<p>On UNIX, the release handler tells the heart program which
command to use to reboot the system. Note that the environment
variable <c>HEART_COMMAND</c>, normally used by the heart
@@ -333,6 +350,25 @@
by using the SASL configuration parameter <c>start_prg</c>, see
<c>sasl(6)</c>.</p>
</section>
+
+ <section>
+ <marker id="restart_emulator_instr"></marker>
+ <title>restart_emulator (low-level)</title>
+ <p>This instruction is not related to upgrades of erts or any of
+ the core applications. It can be used by any application to
+ force a restart of the emulator after all upgrade instructions
+ are executed.</p>
+ <p>There can only be one <c>restart_emulator</c> instruction in
+ a relup script, and it shall always be placed at the end. If
+ the relup is generated by <c>systools:make_relup/3,4</c> this
+ is automatically ensured.</p>
+ <p>When the release handler encounters the instruction, it shuts down
+ the emulator by calling <c>init:reboot()</c>, see
+ <c>init(3)</c>. All processes are terminated gracefully and
+ the system can then be rebooted by the heart program using the
+ new release version. No more upgrade instruction will be
+ executed after the restart.</p>
+ </section>
</section>
<section>
diff --git a/system/doc/design_principles/spec_proc.xml b/system/doc/design_principles/spec_proc.xml
index f0f62891b6..a1c862e004 100644
--- a/system/doc/design_principles/spec_proc.xml
+++ b/system/doc/design_principles/spec_proc.xml
@@ -411,30 +411,48 @@ loop(...) ->
<p>To implement a user-defined behaviour, write code similar to
code for a special process but calling functions in a callback
module for handling specific tasks.</p>
- <p>If it is desired that the compiler should warn for missing
- callback functions, as it does for the OTP behaviours, implement
- and export the function:</p>
+ <p>If it is desired that the compiler should warn for missing callback
+ functions, as it does for the OTP behaviours, add callback attributes in the
+ behaviour module to describe the expected callbacks:</p>
+ <code type="none">
+-callback Name1(Arg1_1, Arg1_2, ..., Arg1_N1) -> Res1.
+-callback Name2(Arg2_1, Arg2_2, ..., Arg2_N2) -> Res2.
+...
+-callback NameM(ArgM_1, ArgM_2, ..., ArgM_NM) -> ResM.</code>
+ <p>where <c>NameX</c> are the names of the expected callbacks and
+ <c>ArgX_Y</c>, <c>ResX</c> are types as they are described in Specifications
+ for functions in <seealso marker="../reference_manual/typespec">Types and
+ Function Specifications</seealso>. The whole syntax of spec attributes is
+ supported by callback attributes.</p>
+ <p>Alternatively you may directly implement and export the function:</p>
<code type="none">
behaviour_info(callbacks) ->
[{Name1,Arity1},...,{NameN,ArityN}].</code>
- <p>where each <c>{Name,Arity}</c> specifies the name and arity of
- a callback function.</p>
+ <p>where each <c>{Name,Arity}</c> specifies the name and arity of a callback
+ function. This function is otherwise automatically generated by the compiler
+ using the callback attributes.</p>
<p>When the compiler encounters the module attribute
- <c>-behaviour(Behaviour).</c> in a module <c>Mod</c>, it will call
- <c>Behaviour:behaviour_info(callbacks)</c> and compare the result
- with the set of functions actually exported from <c>Mod</c>, and
- issue a warning if any callback function is missing.</p>
+ <c>-behaviour(Behaviour).</c> in a module <c>Mod</c>, it will call
+ <c>Behaviour:behaviour_info(callbacks)</c> and compare the result with the
+ set of functions actually exported from <c>Mod</c>, and issue a warning if
+ any callback function is missing.</p>
<p>Example:</p>
<code type="none">
%% User-defined behaviour module
-module(simple_server).
-export([start_link/2,...]).
--export([behaviour_info/1]).
-behaviour_info(callbacks) ->
- [{init,1},
- {handle_req,1},
- {terminate,0}].
+-callback init(State :: term()) -> 'ok'.
+-callback handle_req(Req :: term(), State :: term()) -> {'ok', Reply :: term()}.
+-callback terminate() -> 'ok'.
+
+%% Alternatively you may define:
+%%
+%% -export([behaviour_info/1]).
+%% behaviour_info(callbacks) ->
+%% [{init,1},
+%% {handle_req,2},
+%% {terminate,0}].
start_link(Name, Module) ->
proc_lib:start_link(?MODULE, init, [self(), Name, Module]).
@@ -452,7 +470,7 @@ init(Parent, Name, Module) ->
-module(db).
-behaviour(simple_server).
--export([init/0, handle_req/1, terminate/0]).
+-export([init/0, handle_req/2, terminate/0]).
...</code>
</section>
diff --git a/system/doc/design_principles/sup_princ.xml b/system/doc/design_principles/sup_princ.xml
index 2748f21bbe..5b8fd604c8 100644
--- a/system/doc/design_principles/sup_princ.xml
+++ b/system/doc/design_principles/sup_princ.xml
@@ -160,10 +160,13 @@ init(...) ->
be restarted.</p>
<list type="bulleted">
<item>A <c>permanent</c> child process is always restarted.</item>
- <item>A <c>temporary</c> child process is never restarted.</item>
+ <item>A <c>temporary</c> child process is never restarted
+ (not even when the supervisor's restart strategy
+ is <c>rest_for_one</c> or <c>one_for_all</c> and a sibling's
+ death causes the temporary process to be terminated).</item>
<item>A <c>transient</c> child process is restarted only if it
terminates abnormally, i.e. with another exit reason than
- <c>normal</c>.</item>
+ <c>normal</c>, <c>shutdown</c> or <c>{shutdown,Term}</c>.</item>
</list>
</item>
<item>
@@ -181,8 +184,16 @@ init(...) ->
terminated using <c>exit(Child, kill)</c>.</item>
<item>If the child process is another supervisor, it should be
set to <c>infinity</c> to give the subtree enough time to
- shutdown.</item>
+ shutdown. It is also allowed to set it to <c>infinity</c>, if the
+ child process is a worker.</item>
</list>
+ <warning>
+ <p>Be careful by setting the <c>Shutdown</c> strategy to
+ <c>infinity</c> when the child process is a worker. Because, in this
+ situation, the termination of the supervision tree depends on the
+ child process, it must be implemented in a safe way and its cleanup
+ procedure must always return.</p>
+ </warning>
</item>
<item>
<p><c>Type</c> specifies if the child process is a supervisor or
@@ -341,6 +352,10 @@ call:start_link(id1)</code>
supervisor:terminate_child(Sup, Pid)</code>
<p>where <c>Sup</c> is the pid, or name, of the supervisor and
<c>Pid</c> is the pid of the child.</p>
+ <p>Because a <c>simple_one_for_one</c> supervisor could have many children,
+ it shuts them all down at same time. So, order in which they are stopped is
+ not defined. For the same reason, it could have an overhead with regards to
+ the <c>Shutdown</c> strategy.</p>
</section>
<section>