aboutsummaryrefslogtreecommitdiffstats
path: root/lib/sasl/doc
diff options
context:
space:
mode:
authorSiri Hansen <[email protected]>2011-09-02 12:16:51 +0200
committerSiri Hansen <[email protected]>2011-09-02 12:16:51 +0200
commit23a350702fd05ee45285c01172d2cba7ff9f5029 (patch)
treebf16b4ff2c34578c44099df949c2b174f3913e60 /lib/sasl/doc
parent7ee8080d1127b30c935dfd896a8e78b3a34ee176 (diff)
downloadotp-23a350702fd05ee45285c01172d2cba7ff9f5029.tar.gz
otp-23a350702fd05ee45285c01172d2cba7ff9f5029.tar.bz2
otp-23a350702fd05ee45285c01172d2cba7ff9f5029.zip
Add option purge to release_handler:check_install_release
Given this option, all modules that are to be purged by indicated upgrade,and that can be soft purged, will be purged when all other check of check_install_release have been successfully completed. I added a note under install_release in the reference manual about how to use check_install_release with this new option in order to speed up the execution of install_release. I also added three more test cases for this functionality.
Diffstat (limited to 'lib/sasl/doc')
-rw-r--r--lib/sasl/doc/src/release_handler.xml42
1 files changed, 24 insertions, 18 deletions
diff --git a/lib/sasl/doc/src/release_handler.xml b/lib/sasl/doc/src/release_handler.xml
index 2781412848..5ac0dc1acc 100644
--- a/lib/sasl/doc/src/release_handler.xml
+++ b/lib/sasl/doc/src/release_handler.xml
@@ -159,9 +159,12 @@ old reboot_old permanent
<funcs>
<func>
<name>check_install_release(Vsn) -> {ok, OtherVsn, Descr} | {error, Reason}</name>
+ <name>check_install_release(Vsn,Opts) -> {ok, OtherVsn, Descr} | {error, Reason}</name>
<fsummary>Check installation of a release in the system.</fsummary>
<type>
<v>Vsn = OtherVsn = string()</v>
+ <v>Opts = [Opt]</v>
+ <v>Opt = purge</v>
<v>Descr = term()</v>
<v>Reason = term()</v>
</type>
@@ -179,6 +182,11 @@ old reboot_old permanent
upgrade script.</p>
<p>Returns the same as <c>install_release/1</c>. <c>Descr</c>
defaults to "" if no <c>relup</c> file is found.</p>
+ <p>If the option <c>purge</c> is given, all old code that can
+ be soft purged will be purged after all other checks are
+ successfully completed. This can be useful in order to
+ reduce the time needed by <seealso
+ marker="#install_release/1">install_release</seealso>.</p>
</desc>
</func>
<func>
@@ -300,24 +308,22 @@ release_handler:set_unpacked(RelFile, [{myapp,"1.0","/home/user"},...]).
<c>code:lib_dir(myapp)</c> will return
<c>/home/user/myapp-1.0</c>.</p>
<note>
- <p>Before a new release is installed, the
- <c>release_handler</c> checks that no processes have
- references to old code of any of the modules that are to be
- loaded. This operation can be very time consuming,
- especially if there are many processes in the system, since
- it might cause garbage collections and copying of data.</p>
- <p>If it is desirable to reduce the time spent in this
- function, then <seealso
- marker="#check_install_release/1">check_install_release/1</seealso>
- might be called first. This function does the same check for
- old code, including garbage collection, and can be done in
- the background before actually starting the upgrade by
- calling <c>install_release</c>.</p>
- <p>Code might even be purged (using
- <c>code:purge/1</c>) after
- <c>check_install_release</c> in order to completely
- avoid the check for old code during
- <c>install_release</c>.</p>
+ <p>Installing a new release might be quite time consuming if
+ there are many processes in the system. The reason is that
+ each process must be checked for references to old code
+ before a module can be purged. This check might lead to
+ garbage collections and copying of data.</p>
+ <p>If you wish to speed up the execution of
+ <c>install_release</c>, then you may call <seealso
+ marker="#check_install_release/1">check_install_release</seealso>
+ first, using the option <c>purge</c>. This will do the same
+ check for old code, and then purge all modules that can be
+ soft purged. The purged modules will then no longer have any
+ old code, and <c>install_release</c> will not need to do the
+ checks.</p>
+ <p>Obviously, this will not reduce the overall time for the
+ upgrade, but it will allow checks and purge to be executed
+ in the background before the real upgrade is started.</p>
</note>
</desc>
</func>