[slime-devel] breakage on recent threaded SBCL (was: sbcl threads)
Andreas Fuchs
asf at boinkor.net
Mon Jun 27 09:53:04 UTC 2005
On 2005-06-20, Gábor Melis <mega at 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,
--
Andreas Fuchs, <asf at boinkor.net>, asf at jabber.at, antifuchs
More information about the slime-devel
mailing list