[slime-devel] Re: Slime/SBCL/FreeBSD oddities

Raymond Wiker Raymond.Wiker at fast.no
Fri Dec 5 21:16:23 UTC 2003


Raymond Wiker writes:
 > Luke Gorrie writes:
 >  > Raymond Wiker <Raymond.Wiker at fast.no> writes:
 >  > 
 >  > >  > What happens if you #+nil out this form in swank-sbcl.lisp?
 >  > >  > 
 >  > >  >     (setf (sb-bsd-sockets:non-blocking-mode socket) t)
 >  > > 
 >  > >         Works, thanks!
 >  > > 
 >  > >         Is this the right solution, though? I'm thinking that it might
 >  > > be better to have a safe-read-form (or something) that recognises
 >  > > EAGAIN... 
 >  > 
 >  > We do it like this in the CMUCL backend. It means that a
 >  > single-threaded Lisp will be blocked while it's in a dialogue with
 >  > Emacs. I think it's the Right Way.
 >  > 
 >  > It seems like the main alternative is to implicitly call the
 >  > SERVE-EVENT loop on EWOULDBLOCK. As an Erlang programmer this strikes
 >  > me as a Really Bad Idea, but it might be practical for others :-)
 > 
 >         I've just gone through src/code/fd-streams.lisp and
 > contrib/sb-simple-streams.internal.lisp and copied all code that
 > references sb-unix:ewouldblock into ~/.sbclrc, replacing
 > sb{!,-}-unix:ewouldblock with 35. This does not seem to work, either,
 > though it is possible that fixing unix.lisp and rebuilding would work.
 > I can certainly live with the fix you suggested (this is not connected
 > with the fact that I've done some Erlang programming in the past :-)
 > 
 >         Thanks for all the help, so far. I'll report on the result of
 > a full SBCL rebuild later.

        Ok, I've now rebuilt SBCL on my home machine (also FreeBSD
4.9-STABLE), and the problem still exists. The rebuilt version uses a
patch posted on the SBCL-devel mailing list. The fix suggested earlier
works, though.

        I'd be interested to know if any Linux users see similar
problems with forms exceeding 8192 bytes.





More information about the slime-devel mailing list