Hello list,
To start, I'm new to the list, and I'd like to congratulate everyone on creating such a wonderful piece of software. I've been continually impressed by SLIME ever since I started keeping up with it a few months ago. However, I think I've found a bug in Swank's spawn connection-style. I've been connecting to an already-running sbcl (on Linux) as per the instructions found on on Bill Clemenson's weblog, linked from CLiki's SLIME-HOWTO page.
fatman@hubris:~$ sbcl --load slime.lisp This is SBCL 0.8.13, an implementation of ANSI Common Lisp. More information about SBCL is available at http://www.sbcl.org/. . <snip> . ;; Swank started at port: 4005. *
My slime.lisp is simple: (load "lib/emacs/slime/swank-loader.lisp") (swank::create-swank-server 4005 :spawn #'swank::simple-announce-function t)
Before connecting to Swank for the first time, there are 2 sbcl threads running:
fatman@hubris:~$ ps -e | grep sbcl 9831 pts/0 00:00:04 sbcl 9832 pts/0 00:00:00 sbcl
After running (slime-connect "localhost" 4005), we also see the new reader, control, and repl threads:
fatman@hubris:~$ ps -e | grep sbcl 9831 pts/0 00:00:04 sbcl 9832 pts/0 00:00:00 sbcl 9844 pts/0 00:00:00 sbcl 9845 pts/0 00:00:00 sbcl 9846 pts/0 00:00:00 sbcl
CL-USER> (in-package swank) #<PACKAGE "SWANK"> SWANK> (mapcar (lambda (c) (list (connection.control-thread c) (connection.reader-thread c) (connection.repl-thread c))) *connections*) ((9844 9845 9846))
But, after running (slime-disconnect), only the reader thread has terminated:
fatman@hubris:~$ ps -e | grep sbcl 9831 pts/0 00:00:04 sbcl 9832 pts/0 00:00:00 sbcl 9844 pts/0 00:00:00 sbcl 9846 pts/0 00:00:00 sbcl
With each successive connection and disconnection, two more threads are added. I suspect that's not the intended behavior. :)
First of all, does this happen to anyone else? I'm using the laterst release of SBCL and the 1.0 Alpha release of SLIME, but some of my system libraries are pathetically out of date. I wouldn't be surprised to learn that my own system is the problem.
Secondly, assuming this is a bug, I have come up with a fix. I simply defined a function for the :cleanup slot in the connection struct. My fix is decidedly simple-minded - I just kill the other two threads. It seems to work, but I have no idea if those threads were left alive for some reason, or if there is a better way to get them to terminate. Also, I'm still very new to the Lisp game, and although I've tried to honor your indirection and abstractions, I have no idea if I succeeded.
-Alan
PS- I tried to make the following diff from the current CVS instead of 1.0alpha, but I got these kind of errors on the sbcl console when the connection was closed:
debugger invoked on a UNDEFINED-FUNCTION in thread 10396: The function :DEBUG is undefined.
Linux: The ultimate video game.
fatman@hubris:~/lib/emacs$ diff slime.alan/swank.lisp slime-1.0alpha/swank.lisp 488,491d487 < (defun cleanup-connection-threads (connection) < (kill-thread (connection.control-thread connection)) < (kill-thread (connection.repl-thread connection))) < 599,600c595 < :serve-requests #'spawn-threads-for-connection < :cleanup #'cleanup-connection-threads)) ---
:serve-requests #'spawn-threads-for-connection))
Oops. It looks like I got the polarity wrong on that diff I just sent. Guess it was a long night.
-A
Linux: The ultimate video game.
506a507,510
(defun kill-connection-threads (connection) (kill-thread (connection.control-thread connection) (kill-thread (connection.repl-thread connection))))
613c617,618 < :serve-requests #'spawn-threads-for-connection)) ---
:serve-requests #'spawn-threads-for-connection :cleanup #'kill-connection-threads))
Alan Caulkins fatman@maxint.net writes:
I have come up with a fix. I simply defined a function for the :cleanup slot in the connection struct. My fix is decidedly simple-minded - I just kill the other two threads.
The fix looks right, but it's not working for me. Actually I seem to be having some weird problems reconnecting to SBCL when running `M-x slime' repeatedly.
Thanks for the patch, I'll need to investigate the weirdness a bit before applying.
P.S., please send patches in unidiff format (diff -u). There are some patch-sending notes in the HACKING file that comes with SLIME.
Cheers, Luke