diff options
Diffstat (limited to 'lib/sasl/doc')
| -rw-r--r-- | lib/sasl/doc/src/release_handler.xml | 42 |
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> |