Subject: Re: problems with SCM 'dump'
From: rpw3@rigden.engr.sgi.com (Rob Warnock)
Date: 1998/07/15
Newsgroups: comp.lang.scheme
Message-ID: <6oh9hq$cmq13@fido.engr.sgi.com>
Nicholas J. Pioch <npioch@bbn.com> wrote:
+---------------
| Has anyone successfully gotten the "dump" capability for saving SCM
| images to work on SGI?
+---------------

Haven't tried, but I *have* used a similar facility in MzScheme [see the
primitive procedure "write-image-to-file" in MzScheme 51 and later] on SGI
Irix 5.3. Speeds up the loading of large applications *significantly*!

But... Something about SGI systems to watch out for that I ran into with
the MzScheme facility which will probably also bite you when you get the
SCM version working. SGI systems will "re-quickstart" [see the man pages
"dso(5)", "rqs(1)", and "rqsall(1)"] all of the known-to-the-system shared
libraries and system-installed executables whenever something new is
installed. This "re-quickstarting" process can potentially alter the
addresses of data and code in your executables and/or libraries, rendering
saved Scheme or Lisp "image" files invalid and likely to produce coredumps!

A simple (but ugly) fix is to rebuild all of your saved image files every
time any new software is installed on the system [installed by the standard
SGI "inst" process, that is -- you don't need to worry about any executables
*you* install by just compiling source off the net].

I'm not sure which other systems than SGI, if any, have this notion of
"re-quickstarting" shared dynamic libs & execs. [H-P has something called
"DCE Quickstart", but I don't think it's the same thing.]


-Rob

p.s.
I'm told there is a way at run-time to check the dates of all the DSOs an
executable hooks to. At some point I plan to add such a check to the MzScheme
code that restores an image saved with "write-image-to-file" (but haven't yet,
mea culpa!) and pass it back to the Rice guys. That wouldn't *fix* anything,
but it would at least let the application Scheme code recover by doing
something useful like explicitly "load"ing all the Scheme source again
until you could rebuild the image file again (which the first random user
to run into the mismatch is unlikely to have the privilidges to do)...

-----
Rob Warnock, 7L-551		rpw3@sgi.com   http://reality.sgi.com/rpw3/
Silicon Graphics, Inc.		Phone: 650-933-1673
2011 N. Shoreline Blvd.		FAX: 650-933-4392
Mountain View, CA  94043	PP-ASEL-IA