RFC: Unix 3.11.3-2116 VM

> Unix VM hackers,
>
> I've published a preview of the 3.11.3 Unix VM for the amusement of  
> alpha testers everywhere.  Lots of things are bound to be broken and/
> or forgotten and/or incomplete and/or begging for improvement.  I'm  
> not quite finished tweaking but comments and suggestions are  
> definitely welcome at this stage!
>
> Grab sources from the trunk of Subversion, or look in
>
>  http://squeakvm.org/unix/alpha
>
> for archives of sources and binaries for i386 (Linux, NetBSD,  
> FreeBSD and Solaris) and powerpc (Darwin).  (Files ending in '.sh'  
> are self-extracting archives; run as shell script and follow  
> instructions.)
>
> The noticeable changes since 3.10 are:
>
> 0. Plugins have been regenerated from latest releases
>
> At least for those on squeaksource.  Any hiding in more obscure  
> places might still be stale.
>
> 1. New build process based on CMake
>
> See README in the source archive or platforms/unix/README.CMake in  
> the repository.
>
> 2. Different plugin and FFI library search strategy
>
> The default plugin directory is now the VM binary directory.  This  
> is correct for installed VMs where the binary lives alongside the  
> plugins in /usr/.../lib/squeak/version/squeakvm.  A launcher script  
> installed as /usr/.../bin/squeak figures out where the VM is (either  
> installed or running from a build directory) and adds a -plugins  
> option appropriately.  The script also does the pulse audio OSS  
> kludge if necessary.  (Another script, squeak.sh, is intended to  
> launch Squeak from a menu.  It's begging for improvement.)
>
> SQUEAK_PLUGINS (or the argument to -plugins) can be set to a colon-
> separated list of places to look for plugins.  (Dave can debug one  
> plugin at a time using 'squeakvm -plugins bld/%n:/usr/lib/squeak/
> <version>'.)
>
> Libraries are searched only by whatever mechanisms dlopen() uses.  
> Applications that used to rely on the VM searching every nook and  
> cranny for FFI callouts may have to set LD_LIBRARY_PATH, or whatever  
> local equivalent is provided, to ensure their external functions'  
> libraries are found.
>
> 3. New numbering scheme
>
> The VM is now numbered X.Y.Z-R where X.Y.Z are the version of  
> VMMaker used to generate the Interpreter and plugins, and R is the  
> Subversion repository revision of the Unix support code.  (The  
> archives are named X.Y.Z.R, just because rpmbuild is grumpy  
> otherwise.)
>
> Cheers,
> Ian

> David Farber wrote:
>> On Sep 1, 2009, at 9:28 AM, Ian Piumarta wrote:
>>> Is enabling IMAGE_DUMP in sqUnixMain.c sufficient for what you  
>>> need?  We could also have an option that names an image dump  
>>> file, disabling the dump if no name is given but still printing  
>>> the stack.
>> I was looking at this code earlier this year.  I couldn't convince  
>> myself that the resulting image would actually be usable.  If the  
>> VM just dumps the image, then won't you (at the very least) lose  
>> all your file handles including the handle to the changes file?  
>> And if you've lost your handle to the changes file then the image  
>> won't, for any practical purposes be usable.
>> Am I missing something?
>
> The simulator. It can be used to inspect the contents of an image  
> file regardless of whether you run it or it. Useful for post-mortem  
> analysis.

>
> Here is what happened to me back at the end of March.  I was running  
> a Seaside/Pier site headless [1] on CentOS 5.  For persistency, Pier  
> was supposed to snapshot the image after any relevant changes.  
> Somewhere, somehow an error arose in the snapshot codepath, so Pier  
> stopped snapshotting the image (even though the rest of the app ran  
> fine and was accumulating data).  I tried to manually snapshot the  
> image (and save precious data) but, because the error was in the  
> snapshot codepath, all I managed to do was hang the web interface.  
> Out of the box, Seaside doesn't do any error logging [2] and I wasn't  
> running a VM that had IMAGE_DUMP or stack-printing enabled[3].  So I  
> was stuck with an image that was running (with unsaved data) but  
> completely incommunicado.

> This is probably redundant with what Ian previously described, but  
> here
> is another way to set up your image to do a save when you send SIGUSR2
> to the vm. The image save has little or no impact on the running image
> (i.e. no pause while the files are being written) because it is done
> in a background OS process.
>
>   sigUsr2Semaphore := OSProcess accessor forwardSigUsr2.
>   sigWatcher := [[sigUsr2Semaphore wait.
>     UnixProcess saveImageInBackgroundNicely.
>     (Delay forSeconds: 30) wait] repeat] fork.
>
> This would need to be run at image startup, because #forwardSigUsr2
> sets the signal handler only for the duration of the current session.
>
> I guess you could also use cron to schedule periodic image saves.