[slime-devel] Shutting down Swank within an Image.

Andrew Myers asm198 at gmail.com
Fri Nov 4 15:54:34 UTC 2011

I've got an updated version that seems to work quite well:

(defun aux-save-image (image-name)
  (let ((old-restart excl:*restart-init-function*))
    (setf excl:*restart-init-function*
          (lambda ()
            (dolist (connection swank::*connections*)
              (format t "closing ~a~%" connection)
              (swank::close-connection connection nil nil))
            (when old-restart
              (funcall old-restart))))
    (excl:dumplisp :name image-name)
    (setf excl:*restart-init-function* old-restart)))

Is there anything wrong with doing things this way?  I get the same
number of threads after I restart an image saved this way (i.e. no
left overs from prior runs) and things don't hang.  If this seems like
a clean solution I may add a (close-all-swank-connections) method to
the swank package and make the swank-backend:save-image implementation
for Allegro do something like this.

Does this sounds like a valid solution to the problem that other
Lispers would be happy with?


On Fri, Nov 4, 2011 at 10:39 AM, Jeffrey Cunningham
<jeffrey at jkcunningham.com> wrote:
> On Fri, 04 Nov 2011 06:13:25 -0700, Andrew Myers <asm198 at gmail.com> wrote:
>> As data point I can reliably restart images in which I've executed this
>> form:
>> (setf *restart-init-function*
>> (lambda ()
>> (dolist (connection swank::*connections*)
>> (format t "closing ~a~%" connection)
>> (swank::close-connection connection nil nil))))
>> Without that the reliability ranges from "works most of the time" to
>> "never ever works" depending on the OS I'm testing on. This solution
>> uses a number of non exported swank features and I'm still not sure if
>> it's the right direction to go. Any thoughts?
>> Thanks,
>> Andrew
>> On Fri, Nov 4, 2011 at 8:56 AM, Andrew Myers <asm198 at gmail.com> wrote:
>>> So I've been looking into the problem of restarting a lisp image saved
>>> from Slime.  It appears to me that Swank is still blocked on the
>>> socket listening for connections in the restarted image in some cases
>>> (I'm not sure why it's inconsistent).   As a result when the image is
>>> restarted it's stuck listening on a connection that will never receive
>>> data and can't execute the Swank initialization process to connect to
>>> the new socket which Slime has chosen.
>>> I was thinking that I would implement swank-backend:save-image to
>>> shutdown Swank before dumping the image (or possibly have the restart
>>> function shutdown any existing Swank processes) so there's nothing in
>>> the way of Swank being re-initialized when the image is loaded again.
>>> (Does this sounds like a reasonable thing to do?) I'm not sure how to
>>> do this though, there only seem to be methods for shutting down the
>>> Swank server, not individual connections.  Looking at other
>>> implementations of save-image wasn't very illuminating so I seem to be
>>> missing something.
>>> It looks like the connection struct and the *connections* defvar might
>>> have what I need in it, but there is only sanctioned access to the
>>> most recently opened connection via `default-connection`.  Presumably
>>> I would need to close _all_ *connections*?
>>> Can anyone point me in the right direction?
> I'm not sure this will help, but here's the way I create an executable image
> with swank that works (100% of the time).
> It's SBCL specific but I'm guessing you can generalize it.
> ;; Shut down Swank and anyone else by terminating all threads
> (dolist (thread (sb-thread:list-all-threads))
> (unless (equal sb-thread:*current-thread* thread)
> (sb-thread:terminate-thread thread)))
> ;; Set the function to run on startup of the core executable
> (setf sb-ext:*init-hooks* (list #'start-the-servers))
> ;; Dump core and exit
> (sb-ext:save-lisp-and-die *core* :executable t)
> Note that since all the threads have to be shut down first, you cannot do
> this from within Slime, but from the command line it is:
> sbcl make-core.lisp
> Jeff

More information about the slime-devel mailing list