Recently sbcl switched to using pthreads if it is built with thread support. Sbcl cvs head has a thread-os-thread-slot instead of thread-pid-slot. Its value is a pid in non-threaded builds, and a pthread_t otherwise. Now, pthread_t is an unsigned long on linux/nptl and the high bits are really used so communication with emacs breaks down: the id of the startup thread on my system does not fit into an elisp integer:
1098623904 => 24882080
The patch below adds a mising a thread state and works with os-thread instead of pid. However, the (unsigned-byte 32) communication problem is still there.
Index: swank-sbcl.lisp =================================================================== RCS file: /project/slime/cvsroot/slime/swank-sbcl.lisp,v retrieving revision 1.134 diff -u -r1.134 swank-sbcl.lisp --- swank-sbcl.lisp 11 Jun 2005 16:22:23 -0000 1.134 +++ swank-sbcl.lisp 20 Jun 2005 13:33:38 -0000 @@ -1117,7 +1117,8 @@ (0 :running) (1 :stopping) (2 :stopped) - (3 :dead))) + (3 :dead) + (4 :starting)))
(defimplementation thread-status (thread) (string (%thread-state thread))) @@ -1136,8 +1137,9 @@ (let ((pids (sb-sys:without-gcing (sb-thread::mapcar-threads (lambda (sap) - (sb-sys:sap-ref-32 sap (* sb-vm:n-word-bytes - sb-vm::thread-pid-slot))))))) + (sb-sys:sap-ref-32 sap + (* sb-vm:n-word-bytes + sb-vm::thread-os-thread-slot))))))) (remove :dead pids :key #'%thread-state)))
(defimplementation interrupt-thread (thread fn)
Cheers, Gábor Melis
On 2005-06-20, Gábor Melis mega@hotpop.com wrote:
Recently sbcl switched to using pthreads if it is built with thread support. Sbcl cvs head has a thread-os-thread-slot instead of thread-pid-slot. Its value is a pid in non-threaded builds, and a pthread_t otherwise. Now, pthread_t is an unsigned long on linux/nptl and the high bits are really used so communication with emacs breaks down: the id of the startup thread on my system does not fit into an elisp integer:
1098623904 => 24882080
The patch below adds a mising a thread state and works with os-thread instead of pid. However, the (unsigned-byte 32) communication problem is still there.
I'll chime in here. SLIME as of today (last ChangeLog entry 2005-06-21) refuses to start on a threaded SBCL 0.9.1.65 with swank communication-style set to :spawn.
------------------------------------------------------------------- My *Messages* buffer contains this, after running M-x slime RET: Polling "/tmp/slime.11871".. (Abort with `M-x slime-abort-connection'.) [5 times] Connecting to Swank on port 58251.. Process bridge is installed Lisp connection closed unexpectedly: connection broken by remote peer -------------------------------------------------------------------
------------------------------------------------------------------- *inferior-lisp* with swank:*log-events* set to T says this: [normal loading messages] CL-USER(2): ;; Swank started at port: 58251.
58251 CL-USER(3): WRITE: (:open-dedicated-output-stream 58253)
Process inferior-lisp hangup -------------------------------------------------------------------
------------------------------------------------------------------- *slime-events*: (:open-dedicated-output-stream 58253) -------------------------------------------------------------------
setting swank's communication-style to :fd-handler causes SLIME to start up just fine.
Now, I'm wondering if this is related to the (unsigned-byte 32) problem you mentioned above. If I can do anything more to help the wise SLIME hackers debug this, I will, gladly.
Cheers,
On Monday 27 June 2005 11:53, Andreas Fuchs wrote:
I'll chime in here. SLIME as of today (last ChangeLog entry 2005-06-21) refuses to start on a threaded SBCL 0.9.1.65 with swank communication-style set to :spawn.
Yes, it is the same thing. I didn't press this issue very much, because there is already another sbcl thread patch in the queue that will break slime again in a different way. Fortunately, it has what looks like a reasonably simple and supportable api and slime will not need to mess with sbcl internals anymore.
A pre version of said patch was sent to sbcl-devel along with a slime patch. I mention it only if you want to use slime+sbcl desperately because neither patch is in its final form.
Cheers, Gábor
OK, here is a terrible hack that makes threaded SBCL work with slime. It is based on the observation that the lowest five bits of a thread id are always zero.
It is a temporary "solution" until sbcl 0.9.2 and the thread object based interface.
It is a temporary "solution" until sbcl 0.9.2 and the thread object based interface.
The changed interface is in the sbcl cvs with many bug fixes. 0.9.2 has several deadlock possibilities and is not recommended for serious use. On the bright side threads on x86-64 are supported.
2005-07-01 Gabor Melis mega@hotpop.com
* swank-sbcl.lisp (threaded stuff): make SBCL 0.9.2.9+ work while retaining support for 0.9.2
The thread id mapping code is messy and can potentially exceed 2^27-1 leading to communication problems with emacs.
Gábor
-
Andreas Fuchs -
Gábor Melis