[slime-devel] Signal-driven IO in SBCL on non-Linux/x86

[Helmut Eller]

Brian Mastenbrook <bmastenb at cs.indiana.edu> writes:

> Have any of the SLIME developers tested the new signal-driven IO at
> all on non-linux/x86? 

I haven't.

> It seems to be quite thoroughly-broken for me on
> both Darwin and Solaris: connecting will sometimes hang emacs, 

The CVS version contains some fixes for this, I think.  There was
something like a race condition and it was possible that the first
signal was missed.

> once
> connected messages sometimes need an extra newline to go through, and
> sending any input at all to the actual SBCL repl once connected causes
> a major SBCL hang.

Don't know why this is.  I haven't seen it before.  Signal driven I/O
has the reputation of not being very portable.  Perhaps other kernels
deliver the signal under slightly different conditions.

> Is this expected? 

Of course not.

> Will it improve? 

I don't have access to those OSes, so I can't do much about it.

> I never had any problems with the
> old fd-handler approach.

FWIW, currently SLIME supports three communication "styles":

 - signal driven IO (used with CMUCL and SBCL)
 - thread based (OpenMCL, Allegro, Lispworks, SBCL-mt)
 - vanilla (CLISP)

This can be controlled by setting *swank-in-background* to :sigio,
:spawn, or nil.  Every implementation can be used in "vanilla" style.
In vanilla style we read and processes each request sequentially and
use SIGINT for interrupting.  The drawback of vanilla style is that
nested/pipelined requests are queued on the Lisp side, which may be a
bit confusing at times.  In earlier versions we didn't allow pipelined
requests, but since Emacs is now stateless we don't know what Lisp is
doing and just send every request.  The other styles don't have this
problem because each request is processed immediately.  Fd-handlers
are basically a variant of vanilla style with the same problems.

> Also, FWIW, it seems someone has changed slime.el such that
> slime-connect now attempts to connect to localhost no matter what host
> you supply.

Should be fixed in CVS.

Thank you for complaining :-)

Helmut.