<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tobias C. Rittweiler wrote:
<blockquote cite="mid:%3C87sk9cabtt.fsf@freebits.de%3E" type="cite">
<pre wrap="">"Tobias C. Rittweiler" writes:
</pre>
<blockquote type="cite">
<pre wrap="">Juan Jose Garcia-Ripoll writes:
</pre>
<blockquote type="cite">
<pre wrap="">Slime gets my computer at 100% activity because it has some strange way of
waiting for input: this is a loop over streams, inifite, using
read-char-no-hang without ever waiting. I am sure there are better ways of
doing this. This is in swank-backend.lisp -- do all implementations have
this problem?
(defun wait-for-streams (streams timeout)
(loop
(when (check-slime-interrupts) (return :interrupt))
(let ((ready (remove-if-not #'stream-readable-p streams)))
(when ready (return ready)))
(when timeout (return nil))
(sleep 0.1)))
</pre>
</blockquote>
<pre wrap="">The problem is that not more advanced ways are implemented. Slime can
also me made to use threads, and serve-event, but ECL's backend does not
support that.
I tried to do both in past, but encountered non-obvious problems. I'll
polish up, and commit the work in progress.
</pre>
</blockquote>
<pre wrap=""><!---->
OK, juanjo, I committed the work in progress.
The threading stuff is defined at the end of swank-ecl.lisp.
To activate it, you have to put
;; for debugging messages of the swank server
(setq swank:*log-events* t)
(setq swank:*communication-style* :spawn)
into ~/.swank.lisp
Also make sure to put
(slime-setup '(slime-fancy))
into your .emacs, after (require 'slime).
If you start slime, you'll see it gets stuck.
It gets stuck in ENCODE-MESSAGE in swank-rpc.lisp, before writing to the
STREAM parameter.
The stream that is passed as STREAM parameters comes from:
make-socket-io-stream in swank-ecl.lisp
<- accept-connection in swank-ecl.lisp
<- accept-authenticated-connection in swank.lisp
<- serve-connection in swank.lisp
SERVE-CONNECTION will store the result of MAKE-SOCKET-IO-STREAM into the
SOCKET-IO slot of a CONNECTION.
DISPATCH-EVENT (which is run in a background control thread) will call
ENCODE-MESSAGE with the sockets-io stream.
The first thing the Emacs side will do once a socket connection has been
established is to send
(:emacs-rex
(swank:connection-info) ; <-- expression to be evaluated
"COMMON-LISP-USER" t 1) ; <-- metainformation
over to the Swank server. You can see that in the *slime-events*
buffer. (*slime-events* contains the events sent/received by the Emacs
client side; if swank:*log-events* is T, the Common Lisp swank server
will print events sent/received to error-output.
:EMACS-REX is a Remote-EXpression, or in other words: an RPC.
I.e. the Emacs side wants (SWANK:CONNECTION-INFO) to be evaluated by the
swank server.
Due to *LOG-EVENTS*, the last thing you'll see in *inferior-lisp* is
WRITE: (:return (:ok (:pid 17981
:style :spawn
:lisp-implementation (:type "ECL"
:name "ECL"
:version "10.2.1")
...)))
which is exactly what the Emacs side expects.
But because *slime-events* does only contain the (:EMACS-REX ...), but
no (:RETURN (:OK ...)), this means that this return value is not
transfered over the socket.
Hm, I hope that's enough to get you going.
-T.
</pre>
</blockquote>
Tobias,<br>
<br>
I ran into this issue on MacOSX, and it turned out to be because SLIME
has multiple threads (control and reader threads) which want to read
and write the connection socket stream. The issue (on MacOSX atleast)
was that the standard buffered I/O library (which handles the FILE*
data structure and functions), has been made thread safe, and locks the
file stream when any thread uses it. The tragedy is that there seems to
be only one lock, for both read and write, which means if one thread
locks the stream to read then another thread cannot do anything with
it, not even write. Anyway, the hack I came up with was to modify the
swank-ecl backend to return a two-way-stream with two independent
file-streams for the two directions:<br>
<br>
<tt>(defun socket-make-stream (socket &rest args)<br>
(let ((stream (apply 'sb-bsd-sockets:socket-make-stream socket args)))<br>
(setf (slot-value socket 'sb-bsd-sockets::stream) nil)<br>
stream))<br>
<br>
(defun make-socket-io-stream (socket)<br>
(case (preferred-communication-style)<br>
(:fd-handler<br>
(sb-bsd-sockets:socket-make-stream socket<br>
:output t<br>
:input t<br>
:element-type 'base-char))<br>
(:spawn<br>
(let* ((input (socket-make-stream socket<br>
:direction :input<br>
:element-type 'base-char))<br>
(output (socket-make-stream socket<br>
:direction :output<br>
:element-type 'base-char))<br>
(stream (make-two-way-stream input output)))<br>
(setf (slot-value socket 'sb-bsd-sockets::stream) stream)<br>
stream))))</tt><br>
<br>
Admittedly this hack is ugly, as it knows way too much about what the
underlying socket implementation is doing. The right place to fix this
is probably in SOCKETS::SOCKET-MAKE-STREAM, based on a DIRECTION
keyword arg or something.<br>
<br>
Here's a link to the complete set of patches:<br>
<br>
<a class="moz-txt-link-freetext" href="http://github.com/kriyative/ecl-iphone-builder/blob/master/swank-ecl-patches.txt">http://github.com/kriyative/ecl-iphone-builder/blob/master/swank-ecl-patches.txt</a><br>
<br>
Anyway, hope this is useful in your efforts.<br>
<br>
Cheers,<br>
<br>
-ram<br>
<br>
</body>
</html>