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/