Raymond Wiker writes:
Luke Gorrie writes:
Raymond Wiker Raymond.Wiker@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 mightbe 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 andcontrib/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 ofa 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.