[slime-devel] SLIME snapshot (unix, sbcl): take3 (+ background-save-image)

[Anton Kovalenko]

>> Slime-snapshot is patched to use
>> background-save-image in the presence of prefix argument: 
>> C-u M-x slime-snapshot <RET>. Without a prefix argument, it uses
>> normal, synchronous (save-image).

Helmut Eller <heller at common-lisp.net> writes:

> This asynchronous mode seems complicated.  Saving the image doesn't take
> that long to justify a complicated interface.  

It depends on the image size. On my AMD x86-64, it takes 200Mb of the
core to dump MCCLIM(+examples), climacs and closure. Rollback/restart
(especially to the last loaded core) takes "no time at all" (visually),
while dumping may take 20-30 seconds.

Of course it's possible to have a nice Common Lisp environment without
dumping all these things; but, specifically, the point of *snapshot and
rollback* functions is to work with a fully loaded environment, not with
"normal" core sizes suitable for deployment or software distribution.

> Apparently you did that to wait for a reply on a pipe; but save-image
> (the normal synchronous variant) could do that by calling serve-events
> until the reply arrives.

It makes sense (and may be more suitable for other implementations).
SBCL provides a convenient way to handle closed pipe without explicitly
waiting for it, but it may be harder with others. 

However, the _interface_ (background-save-image) is not so complicated
after all, it's the implementation that uses SBCL specifics that is
complicated. 

Future reimplementations of (background-save-image) for other backends
may as well behave as you described, running (serve-event) and checking
for a process status, and calling completion function afterwards.  The
only change required is to *document* at (definterface
background-save-image..) that it doesn't have to return immediately.
(it may be even better to merge background-save-image *interface* with
ordinary save-image: I separated it out because I would have both
&optional and &key parameters if I chose to keep (save-image)
backward-compatible).

Keeping fully asynchronous implementation for SBCL has one more major
advantage: with #+(and sbcl unix) timers, I may schedule periodic
background checkpoints in SBCL; it works without initiating anything
from emacs, but still reports to emacs about successful dumps. *This*
use case gets significantly more complicated if we prefer synchronous
(serve-event) while waiting for the child process completion.

(A propos, waiting for it at all is not mandatory; waitpid may be called
immediately with WNOHANG and leave the child process in
"fire-and-forget" mode; currently, desire to report completion status to
Emacs is my only reason to do otherwise).

-- 
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia