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.

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>