<div class="gmail_quote">On Tue, Feb 16, 2010 at 6:10 PM, Marko Kocić <span dir="ltr"><<a href="mailto:marko.kocic@gmail.com">marko.kocic@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
CC-ing ecl-list since this might look similar to problems that ecl git<br>
currenty have with new slime.<br></blockquote><div><br></div><div>It does not seem that similar: here the error does not result in a stack overflow. </div></div><br>Regardung usocket, let me comment on a change that happened recently in ECL. The port of Slime to ECL uses the SB-SOCKETs package. So far so good. The problem is that Slime (or Swank) sets up threads that concurrently read and write to the socket stream. More precisely, one thread may be listening 100% of the time while others write to the same communication channel.<div>
<br></div><div>That should be fine, but the problem is that ANSI C streams may lock and ECL is using internally those streams for implementing buffered sockets. More precisely, ECL used an I/O FILE stream for the same socket. This results in Slime being locked due to the listening thread, that prevents all communication from ECL back to Emacs.</div>
<div><br></div><div>The solution we (actually Ram) came up with is to associate a two-way stream to the socket. This is now the stream that is built by socket-make-stream and which is stored in the appropriate slots of the socket class. This seemingly insignificant change is not: there are many operations that can not be performed on two-way streams, such as seek or close.</div>
<div><br></div><div>So, I am just wondering whether usocket uses the socket streams in a way that the latest change may cause troubles.</div><div><br></div><div>Just talking out of ignorance, since I do not use usocket myself.</div>
<div><br></div><div>Juanjo<br clear="all"><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com">http://juanjose.garciaripoll.googlepages.com</a><br>

</div>