[slime-devel] SLIME snapshot (unix, sbcl): take3 (+ background-save-image)
Hello SLIME developers, New variant of slime-snapshot proposed update (for SBCL+unix) is attached. Implementation dependencies were moved where they belong, i.e. into SBCL backend. This new variant includes a new interface, with SBCL+unix implementation, namely, background-save-image: while the image is dumped, the main REPL remains available; success or failure is reported with a background message. 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). -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
* Anton Kovalenko [2010-08-20 10:06] writes:
Hello SLIME developers,
I guess I'll wait with committing this until things settle down :-)
New variant of slime-snapshot proposed update (for SBCL+unix) is attached. Implementation dependencies were moved where they belong, i.e. into SBCL backend.
This new variant includes a new interface, with SBCL+unix implementation, namely, background-save-image: while the image is dumped, the main REPL remains available; success or failure is reported with a background message. 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).
This asynchronous mode seems complicated. Saving the image doesn't take that long to justify a complicated interface. 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. Helmut
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@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
* Anton Kovalenko [2010-08-20 11:30] 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.
6-10 MB per second seems slow. Hmm.. I guess slow is the SBCL way :-) [...]
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.
OK, that sounds somewhat useful. I committed it with some minor modifications. Helmut
participants (2)
-
Anton Kovalenko -
Helmut Eller