0.8.8.30:

[sbcl.git] / src / code / save.lisp

diff --git a/src/code/save.lisp b/src/code/save.lisp
index 74a6906..76b7b95 100644 (file)
--- a/src/code/save.lisp
+++ b/src/code/save.lisp
@@ -17,9 +17,9 @@
 \f
 ;;;; SAVE-LISP-AND-DIE itself
 
-(sb!alien:def-alien-routine "save" (sb!alien:boolean)
-  (file sb!c-call:c-string)
-  (initial-function (sb!alien:unsigned #.sb!vm:n-word-bits)))
+(sb!alien:define-alien-routine "save" (sb!alien:boolean)
+  (file sb!alien:c-string)
+  (initial-fun (sb!alien:unsigned #.sb!vm:n-word-bits)))
 
 ;;; FIXME: When this is run without the PURIFY option,
 ;;; it seems to save memory all the way up to the high-water mark,
@@ -28,15 +28,25 @@
 ;;; (But with the PURIFY option it seems to work OK.)
 (defun save-lisp-and-die (core-file-name &key
                                         (toplevel #'toplevel-init)
-                                        (purify nil)
+                                        (purify t)
                                         (root-structures ())
                                         (environment-name "auxiliary"))
   #!+sb-doc
-  "Saves a CMU Common Lisp core image in the file of the specified name,
-  killing the current Lisp invocation in the process (unless it bails
-  out early because of some argument error or something).
+  "Save a \"core image\", i.e. enough information to restart a Lisp
+  process later in the same state, in the file of the specified name.
 
-  The following &KEY args are defined:
+  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.
+  This isn't because we like it this way, but just because there don't
+  seem to be good quick fixes for either limitation and no one has been
+  sufficiently motivated to do lengthy fixes.
+
+  The following &KEY arguments are defined:
     :TOPLEVEL
        The function to run when the created core file is resumed.
        The default function handles command line toplevel option
@@ -47,13 +57,15 @@
        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.
@@ -63,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