[usocket-devel] [Ecls-list] ECL support

[Juan Jose Garcia-Ripoll]

On Tue, Feb 16, 2010 at 6:10 PM, Marko Kocić <marko.kocic at gmail.com> wrote:

> CC-ing ecl-list since this might look similar to problems that ecl git
> currenty have with new slime.
>

It does not seem that similar: here the error does not result in a stack
overflow.

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.

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.

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.

So, I am just wondering whether usocket uses the socket streams in a way
that the latest change may cause troubles.

Just talking out of ignorance, since I do not use usocket myself.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/usocket-devel/attachments/20100216/7dcaed29/attachment.html>