[slime-devel] Re: [Sbcl-devel] Slime and :sb-futex on recent CVS SBCLs

This isn't just about CVS SBCL; SB-FUTEX was removed last month before the 0.8.21 release On Tue, Apr 19, 2005 at 01:56:21PM +0200, Vincent Arkesteijn wrote:
A somewhat related problem, which will be uncovered by fixing the one that Andreas describes, surfaces when running SLIME+SBCL on a non-NPTL 2.4 kernel. :sb-thread is still on *features*, so swank:*communication-style* will be set to :spawn, but calling make-thread will then fail. Not nice.
Possible solutions: 1) Remove :sb-thread from *features* when running on a non-NPTL kernel.
I think this (and the consequently necessary changes to the fasl compatibility checker) is probably TRT, but not this close to a release.
2) Add some function or variable to SBCL that can be used to check whether threads actually work, and change SLIME to use that.
* (defun communication-style () (if (and (member :sb-thread *features*) (not (sb-alien:extern-alien "linux_no_threads_p" sb-alien:boolean))) :spawn :fd-handler)) COMMUNICATION-STYLE * (communication-style) :SPAWN ... but note that this uses implementation-internal stuff and is not guaranteed to stay working. As the useful working life of any SLIME version on SBCL rarely exceeds three months anyway, that might not be such a big deal -dan

dan@telent.net writes:
This isn't just about CVS SBCL; SB-FUTEX was removed last month before the 0.8.21 release
Thanks for chiming in!
On Tue, Apr 19, 2005 at 01:56:21PM +0200, Vincent Arkesteijn wrote:
A somewhat related problem, which will be uncovered by fixing the one that Andreas describes, surfaces when running SLIME+SBCL on a non-NPTL 2.4 kernel. :sb-thread is still on *features*, so swank:*communication-style* will be set to :spawn, but calling make-thread will then fail. Not nice.
Possible solutions: 1) Remove :sb-thread from *features* when running on a non-NPTL kernel.
I think this (and the consequently necessary changes to the fasl compatibility checker) is probably TRT, but not this close to a release.
2) Add some function or variable to SBCL that can be used to check whether threads actually work, and change SLIME to use that.
* (defun communication-style () (if (and (member :sb-thread *features*) (not (sb-alien:extern-alien "linux_no_threads_p" sb-alien:boolean))) :spawn :fd-handler))
This works for me with :sb-thread on 2.6 and I have committed it. It would be great if people can quickly cvs update and test that (swank-backend:preferred-communication-style) returns the right thing on these platforms: Linux 2.4 non-NPTL: :FD-HANDLER Linux 2.4 NPTL: :SPAWN OSX: :FD-HANDLER

Luke Gorrie <luke@synap.se> writes:
It would be great if people can quickly cvs update and test that (swank-backend:preferred-communication-style) returns the right thing on these platforms:
Linux 2.4 non-NPTL: :FD-HANDLER Linux 2.4 NPTL: :SPAWN OSX: :FD-HANDLER
confirmed on osx (10.3.9) -- -Marco Ring the bells that still can ring. Forget the perfect offering. There is a crack in everything. That's how the light gets in. -Leonard Cohen
participants (3)
-
dan@telent.net
-
Luke Gorrie
-
Marco Baringer