[slime-devel] cmucl multithread problem
Using cmucl 18e and a CVS from a couple of days ago. (mp::startup-idle-and-top-level-loops) from slime-repl hangs slime-repl but works when ran from inferior-lisp (slime-repl still works afterwards). Upgraded to latest CVS and now the inferior-lisp is taken up by the slime server, while before I was able to use both inferior-lisp and slime-repl. Hacked a fix in slime.el but is nonportable. Started the mutithreading from slime and placed slime server into a thread. (defun slime-maybe-start-lisp () "Start an inferior lisp unless one is already running." (unless (get-buffer-process (get-buffer "*inferior-lisp*")) (call-interactively 'inferior-lisp) (comint-proc-query (inferior-lisp-proc) "(mp::startup-idle-and-top-level-loops)") (comint-proc-query (inferior-lisp-proc) (format "(load %S)\n" (concat slime-path slime-backend))))) (defun slime-start-swank-server () "Start a Swank server on the inferior lisp." (comint-proc-query (inferior-lisp-proc) (format "(mp::make-process (lambda () (swank:start-server %S)) :name \"slime\")\n" (slime-swank-port-file))))
William Conrad Halliburton <will@licentiae.com> writes:
(defun slime-maybe-start-lisp () "Start an inferior lisp unless one is already running." (unless (get-buffer-process (get-buffer "*inferior-lisp*")) (call-interactively 'inferior-lisp) (comint-proc-query (inferior-lisp-proc) "(mp::startup-idle-and-top-level-loops)") (comint-proc-query (inferior-lisp-proc) (format "(load %S)\n" (concat slime-path slime-backend)))))
We also have a ~/.swank.lisp file where you can add custom startup like this idle-loop thread.
(defun slime-start-swank-server () "Start a Swank server on the inferior lisp." (comint-proc-query (inferior-lisp-proc) (format "(mp::make-process (lambda () (swank:start-server %S)) :name \"slime\")\n" (slime-swank-port-file))))
Do you know how threads interact with SERVE-EVENT in CMUCL? SLIME-wise it's probably fairly safe if we are always talking to the same thread. But it would get really nasty if you e.g. spawn off new threads that inherit our *debugger-hook* and I/O streams and all end up trying to talk to Emacs at once. We don't handle that at all. -Luke
William Conrad Halliburton:
Using cmucl 18e and a CVS from a couple of days ago. (mp::startup-idle-and-top-level-loops) from slime-repl hangs slime-repl but works when ran from inferior-lisp (slime-repl still works afterwards).
slime-repl on CMUCL 18e doesn't work with expressions consisting of more than ~450 characters. I followed a hint of Helmut on cmucl-imp, and set the last parameter of the call to system:read-n-bytes in lisp::read-into-simple-string to t. That seems to fix the problem with mp::startup-idle-and-top-level-loops called from cmucl-init.
Wolfhard Buß wrote:
William Conrad Halliburton:
Using cmucl 18e and a CVS from a couple of days ago. (mp::startup-idle-and-top-level-loops) from slime-repl hangs slime-repl but works when ran from inferior-lisp (slime-repl still works afterwards).
slime-repl on CMUCL 18e doesn't work with expressions consisting of more than ~450 characters. I followed a hint of Helmut on cmucl-imp, and set the last parameter of the call to system:read-n-bytes in lisp::read-into-simple-string to t. That seems to fix the problem with
Yes, this is a known bug which is fixed in the latest snapshots and will also be fixed for 19a. I'm not 100% sure, but if you set the last parameter to T, you'll now get errors on EOF, which might not be the right thing. I think there was a replacement function posted that doesn't have this issue. You can put this in your .cmucl-init.lisp. Ray
participants (4)
-
Luke Gorrie -
Raymond Toy -
wbuss＠gmx.net -
William Conrad Halliburton