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

[Brian Mastenbrook]

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 at cs.indiana.edu
http://cs.indiana.edu/~bmastenb/