Hello,
Have any of the SLIME developers tested the new signal-driven IO at all on non-linux/x86? It seems to be quite thoroughly-broken for me on both Darwin and Solaris: connecting will sometimes hang emacs, 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.
Is this expected? Will it improve? I never had any problems with the old fd-handler approach.
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.
Brian -- Brian Mastenbrook bmastenb@cs.indiana.edu http://cs.indiana.edu/~bmastenb/
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.
On Feb 21, 2004, at 3:16 AM, Helmut Eller wrote:
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.
CVS seems much improved, thank you.
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.
*Cough* Luke has ssh access to my G5, so perhaps there should be some more testing done on other platforms :-)
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.
If signal-driven IO is causing portability problems though, why not allow the option of fd-handlers on SBCL?
Thank you for complaining :-)
Helmut.
-- Brian Mastenbrook bmastenb@cs.indiana.edu http://cs.indiana.edu/~bmastenb/
Brian Mastenbrook bmastenb@cs.indiana.edu writes:
*Cough* Luke has ssh access to my G5, so perhaps there should be some more testing done on other platforms :-)
Perhaps. The other strategy is to let the users test. People who care about SLIME on those platforms will send bug reports. If no one cares, no time is wasted on testing.
However, if you'd like to give an account on your machine, I could be inclined to run some tests on it :-)
If signal-driven IO is causing portability problems though, why not allow the option of fd-handlers on SBCL?
OK, the CVS supports fd-handlers. You can enable it by adding something like this to your ~/.swank.lisp:
(setq swank::*swank-in-background* :fd-handler)
Helmut.
-
Brian Mastenbrook -
Helmut Eller