Brian Mastenbrook bmastenb@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.