Luke Gorrie writes:

Raymond Wiker Raymond.Wiker@fast.no writes:

...

    FreeBSD 4.9 Stable, SBCL 0.8.6.21, current SLIME.

    Hi. I have a Lisp file that has some large forms (a defconst

for a vector holding 1024 integers, for instance).

    If I hit C-c C-e over this form, it is evaluated in the

*inferior-lisp* buffer.

    If I hit C-c C-c, I get a "broken pipe" error. I've tried

reducing the size of the vector, and I see this problem down to (about) 480 characters. This is just below the "pipesize" limit on my box, which is 512.

Are you running SLIME in any exotic way? Who reports the broken pipe, Emacs or Lisp?

With SBCL "0.8.5.50" from CVS a ways back on Linux I can't reproduce this, even with e.g. (defconstant foo #(42 ... 42)) with 25KB of 42's. I think I can get SBCL onto a FreeBSD box around here though.

Here's the first few items from the "Lossage" buffer in XEmacs:

Recent minibuffer messages (most recent first):

Operation not allowed or error during operation: "SIGPIPE raised on process; closed it", "SLIME Lisp" Connected to Swank server on port 2261. Let the hacking commence! Connecting to Swank on port 2261.. Polling "/tmp/raw/slime.254".. (Abort with `M-x slime-disconnect'.)

And the output from SBCL:

* ;; Connection to Emacs lost. ;; [couldn't read from #<FILE-STREAM for "a constant string" {48E50039}>: Resource temporarily unavailable]

debugger invoked on a SIMPLE-ERROR in thread 89722: (#<SB-IMPL::HANDLER INPUT on BOGUS descriptor 6: #>) has a bad file descriptor.

You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name): 0: [REMOVE-THEM] Remove bogus handlers. 1: [RETRY-THEM ] Retry bogus handlers. 2: [CONTINUE ] Go on, leaving handlers marked as bogus. 3: [ABORT ] Reduce debugger level (leaving debugger, returning to toplevel). 4: [TOPLEVEL ] Restart at toplevel READ/EVAL/PRINT loop. (SB-IMPL::HANDLER-DESCRIPTORS-ERROR 0)[:EXTERNAL] 0]

Hum... this might also be an XEmacs issue? My XEmacs is

XEmacs 21.4 (patch 12) "Portable Code" [Lucid] (i386--freebsd) of Sun Aug 10 2003 on raw.grenland.fast.no

The sequence seems to be that SBCL gets error code EAGAIN ("Resource temporarily unavailable" is a dead giveaway :-), and closes the socket. Then, XEmacs gets a sigpipe, and closes its end of the pipe.

Soooo, this looks like an SBCL issue, but why does this not happen with C-c C-e? Are characters sent in different ways to SBCL with C-c C-e and C-c C-c?

Luke Gorrie writes:

Raymond Wiker Raymond.Wiker@fast.no writes:

...

    Soooo, this looks like an SBCL issue, but why does this not

happen with C-c C-e? Are characters sent in different ways to SBCL with C-c C-e and C-c C-c?

Yes. C-c C-c is a SLIME command that sends the expression over a socket, whereas C-c C-e is an `inf-lisp' command that essentially pastes it into the listener in *inferior-lisp*. (We have these confusing inf-lisp bindings because they merge them directly into the lisp-mode keymap.)

I assume the "broken pipe" must refer to the TCP socket. Can you get any insight from strace'ing xemacs?

"Broken pipe" is reported from Emacs, but I suspect that the cause of this is that SBCL does not handle EAGAIN correctly in whatever operation it is using to read from the pipe. This code is probably somewhere inside sb-bsd-sockets (or possible inside gray-streams or simple-streams), so I'll start looking at this now.

Note that, under linux, the default pipe size is 8192 bytes (under RedHat 7.3, at least), so the example below is likely to work for you. If you repeat the sequence two or three times, you may or may not see something interesting :-)

And just in case, can you send the exact form you're testing with? I tried again with a huge defconstant on linux with XEmacs 21.5beta16 but that didn't reproduce it either.

Here goes:

(defparameter *truth-table* (vector 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 190 191 159 183 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 190 191 159 183 191 191 191 191 191 191 191 191 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 62 63 31 55 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 62 63 31 55 63 63 63 63 63 63 63 63 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 190 191 159 183 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 190 191 159 183 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 190 191 159 183 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 190 191 159 183 191 191 191 191 191 191 191 191

191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 189 187 175 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 189 187 175 191 191 191 191 191 191 191 191 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 61 59 47 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 61 59 47 63 63 63 63 63 63 63 63 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 189 187 175 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 189 187 175 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 189 187 175 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 189 187 175 191 191 191 191 191 191 191 191

191 191 191 191 191 191 191 191 255 255 255 255 255 255 255 255 191 191 191 191 190 191 159 183 255 255 255 255 255 255 255 255 191 191 191 191 191 191 191 191 255 255 255 255 255 255 255 255 191 191 191 191 190 191 159 183 255 255 255 255 255 255 255 255 63 63 63 63 63 63 63 63 127 127 127 127 127 127 127 127 63 63 63 63 62 63 31 55 127 127 127 127 127 127 127 127 63 63 63 63 63 63 63 63 127 127 127 127 127 127 127 127 63 63 63 63 62 63 31 55 127 127 127 127 127 127 127 127 191 191 191 191 191 191 191 191 255 255 255 255 255 255 255 255 191 191 191 191 190 191 159 183 255 255 255 255 255 255 255 255 191 191 191 191 191 191 191 191 255 255 255 255 255 255 255 255 191 191 191 191 190 191 159 183 255 255 255 255 255 255 255 255 191 191 191 191 191 191 191 191 255 255 255 255 255 255 255 255 191 191 191 191 190 191 159 183 255 255 255 255 255 255 255 255 191 191 191 191 191 191 191 191 255 255 255 255 255 255 255 255 191 191 191 191 190 191 159 183 255 255 255 255 255 255 255 255

191 191 191 191 191 191 191 191 255 255 255 255 255 255 255 255 191 191 191 191 191 189 187 175 255 255 255 255 255 255 255 255 191 191 191 191 191 191 191 191 255 255 255 255 255 255 255 255 191 191 191 191 191 189 187 175 255 255 255 255 255 255 255 255 63 63 63 63 63 63 63 63 127 127 127 127 127 127 127 127 63 63 63 63 63 61 59 47 127 127 127 127 127 127 127 127 63 63 63 63 63 63 63 63 127 127 127 127 127 127 127 127 63 63 63 63 63 61 59 47 127 127 127 127 127 127 127 127 191 191 191 191 191 191 191 191 255 255 255 255 255 255 255 255 191 191 191 191 191 189 187 175 255 255 255 255 255 255 255 255 191 191 191 191 191 191 191 191 255 255 255 255 255 255 255 255 191 191 191 191 191 189 187 175 255 255 255 255 255 255 255 255 191 191 191 191 191 191 191 191 255 255 255 255 255 255 255 255 191 191 191 191 191 189 187 175 255 255 255 255 255 255 255 255 191 191 191 191 191 191 191 191 255 255 255 255 255 255 255 255 191 191 191 191 191 189 187 175 255 255 255 255 255 255 255 255))

Helmut Eller writes:

Raymond Wiker Raymond.Wiker@fast.no writes:

...

    Here goes:

(defparameter *truth-table* (vector 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191

My SBCL 0.8.6.13 goes into an endless loop or something when I enter:

(compile nil '(lambda nil (defparameter *truth-table* ...)))

Could be a different problem - I've seen my PowerBook taking up to about 70 seconds compiling this form. Try replacing

(vector ...

with

#.(vector ...

or

#( ...

Helmut Eller writes:

Raymond Wiker Raymond.Wiker@fast.no writes:

...

    Could be a different problem - I've seen my PowerBook taking

up to about 70 seconds compiling this form. Try replacing

            (vector ...

with

            #.(vector ...

Indeed that worked. Another question: what is the value of EAGAIN and EWOULDBLOCK on FreeBSD? They are both 11 on Linux.

EAGAIN and EWOULDBLOCK are both 35 on FreeBSD... 11 is EDEADLK with the comment

/* Resource deadlock avoided */ /* 11 was EAGAIN */

I don't think this is the problem; looking at the definition for socket-receive in sb-bsd-sockets/sockets.lisp, I see that EAGAIN is not handled there. There is a comment in sqank-sbcl.lisp that indicates that EAGAIN should be detected and handled there.

Luke Gorrie writes:

Raymond Wiker Raymond.Wiker@fast.no writes:

...

    I don't think this is the problem; looking at the definition

for socket-receive in sb-bsd-sockets/sockets.lisp, I see that EAGAIN is not handled there. There is a comment in sqank-sbcl.lisp that indicates that EAGAIN should be detected and handled there.

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...

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 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.

Raymond Wiker Raymond.Wiker@fast.no writes:

    EAGAIN and EWOULDBLOCK are both 35 on FreeBSD... 11 is EDEADLK

with the comment

Ah, forgot to ask, what is sb-unix:ewouldblock? I seems that is hardcoded to 11 in unix.lisp. IIUC sb-bsd-sockets just uses fd-streams and not send/receive stuff.

Helmut Eller e9626484@stud3.tuwien.ac.at writes:

Raymond Wiker Raymond.Wiker@fast.no writes:

...

    Here goes:

(defparameter *truth-table* (vector 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191 191

My SBCL 0.8.6.13 goes into an endless loop or something when I enter:

(compile nil '(lambda nil (defparameter *truth-table* ...)))

Can someone confirm this?

Long but not endless for me (in my older SBCL on Linux): it finishes successfully after about 40 seconds (1.7Ghz machine). If I change "(vector " to "#(" then it's very fast.

-Luke