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

[Raymond Wiker]

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.