All,
I'm experimenting moving over a body of code from LispWorks to SBCL and I've got some multithreaded code. When using LW, I'd just start up a LW core image on a command line, manually start up swank, then do slime-connect a couple of times, and use the 2 repls to experiment / debug the multithreaded code. Specifically, I've got a shared queue that waits when empty; I'd call the dequeue in repl 1, see that it properly waits, then enqueue in repl 2 and ideally see the enqueue return in repl 1; crude, but simple.
I try doing the same thing in SBCL. I start up SBCL in a shell, start up swank, and I can start up the 1st repl with slime-connect. When I attempt a 2nd slime-connect, emacs loses the connection to SBCL and I get this in the shell running SBCL:
WRITE: (:return (:ok (:pid 6102 :style :spawn :lisp-implementation (:type "SBCL" :name "sbcl" :version "0.9.8") :machine (:instance "localhost.localdomain" :type "X86" :version "Intel(R) Pentium(R) 4 CPU 2.80GHz") :features (:acl-compat :cl-ppcre it.bese.arnesi.mopp::have-mop :split-sequence :asdf :sb-thread :ansi-cl :common-lisp :sbcl :unix :sb-doc :sb-test :sb-package-locks :sb-unicode :sb-source-locations :ieee-floating-point :x86 :elf :linux :gencgc :stack-grows-downward-not-upward :c-stack-is-control-stack :stack-allocatable-closures :linkage-table :os-provides-dlopen :os-provides-dladdr :os-provides-putwc) :package (:name "COMMON-LISP-USER" :prompt "CL-USER"))) 1) WRITE: (:open-dedicated-output-stream 32783) READ: "(:emacs-rex (swank:connection-info) "COMMON-LISP-USER" :repl-thread 1) " DISPATCHING: (:EMACS-REX (SWANK:CONNECTION-INFO) "COMMON-LISP-USER" :REPL-THREAD 1) ;; Event history end. ;; Connection to Emacs lost. [ ;; condition: The value NIL is not of type SB-THREAD:THREAD. ;; type: TYPE-ERROR ;; encoding: :ISO-LATIN-1-UNIX style: :SPAWN dedicated: T]
<sbcl is locked, so I hit control-c and get this:>
debugger invoked on a SIMPLE-CONDITION in thread #<THREAD "initial thread" {A66D379}>: interrupted at #XB7FFF402
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name): 0: [CONTINUE] Return from SB-UNIX:SIGINT. 1: [ABORT ] Exit debugger, returning to top level.
(SB-UNIX::SIGINT-HANDLER #<unavailable argument> #<unavailable argument> #.(SB-SYS:INT-SAP #XB7B9C5FC)) 0]
I'm running SBCL 0.9.8, slime from cvs of 12/27/2005, and Fedora Core 4. I've got a function for starting up swank:
(defun start-swank (&key (port swank::default-server-port) (style swank:*communication-style*) (dont-close t)) "Start the SLIME swank server, listening on PORT. Multiple connections are allowed." (swank:create-server :port port :style style :dont-close dont-close))
and I call it with default arguments, (start-swank).
Is it possible to drive SBCL like I mentioned at the top with LispWorks and if so, how do I do it?
Thanks!
Glenn Ehrlich
* Glenn Ehrlich [2006-01-10 20:44+0100] writes:
Is it possible to drive SBCL like I mentioned at the top with LispWorks and if so, how do I do it?
There was a race condition in the thread initialization code which only occurred when slime-connect was invoked in the REPL buffer. It should be fixed in the CVS version.
Helmut.
Helmut Eller <heller <at> common-lisp.net> writes:
- Glenn Ehrlich [2006-01-10 20:44+0100] writes:
Is it possible to drive SBCL like I mentioned at the top with LispWorks and if so, how do I do it?
There was a race condition in the thread initialization code which only occurred when slime-connect was invoked in the REPL buffer. It should be fixed in the CVS version.
Helmut.
Helmut,
That's good news, thanks a lot.
I eventually fixed my problem by being more disciplined, which I should have done in the first place. I wrote fiveAM unit tests to spawn off carefully setup & interacting threads. Much better than hand testing in the REPL.
Glenn
Helmut Eller <heller <at> common-lisp.net> writes:
There was a race condition in the thread initialization code which only occurred when slime-connect was invoked in the REPL buffer. It should be fixed in the CVS version.
Helmut.
I've confirmed that the latest CVS version does fix this problem. Once again, thank you very much!
Glenn