0.8.8.21:
[sbcl.git] / src / code / save.lisp
index 2356255..76b7b95 100644 (file)
@@ -38,6 +38,7 @@
   This implementation is not as polished and painless as you might like: 
     * It corrupts the current Lisp image enough that the current process
       needs to be killed afterwards.
+    * It will not work if multiple threads are in use.
     * There is absolutely no binary compatibility of core images between
       different runtime support programs. Even runtimes built from the same
       sources at different times are treated as incompatible for this purpose.
        allocated objects into static space so that they stay pure. This takes
        somewhat longer than the normal GC which is otherwise done, but it's
        only done once, and subsequent GC's will be done less often and will
-       take less time in the resulting core file. See PURIFY.
+       take less time in the resulting core file. See the PURIFY function.
     :ROOT-STRUCTURES
        This should be a list of the main entry points in any newly loaded
        systems. This need not be supplied, but locality and/or GC performance
-       may be better if they are. Meaningless if :PURIFY is NIL. See PURIFY.
+       may be better if they are. Meaningless if :PURIFY is NIL. See the
+       PURIFY function.
     :ENVIRONMENT-NAME
-       This is also passed to PURIFY when :PURIFY is T. (rarely used)
+       This is also passed to the PURIFY function when :PURIFY is T.
+       (rarely used)
 
   The save/load process changes the values of some global variables:
     *STANDARD-OUTPUT*, *DEBUG-IO*, etc.
@@ -72,8 +75,6 @@
       This is reinitialized to reflect the working directory where the
       saved core is loaded."
 
-  #!+mp (sb!mp::shutdown-multi-processing)
-  ;; FIXME: What is this for? Explain.
   (when (fboundp 'cancel-finalization)
     (cancel-finalization sb!sys:*tty*))
   ;; FIXME: Would it be possible to unmix the PURIFY logic from this