[Ecls-list] Problems with slime

[Matthew Mondor]

On Tue, 09 Feb 2010 11:38:49 -0800
Ram Krishnan <kriyative at gmail.com> wrote:

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

This reminds me that ECL now uses unbuffered streams on file descriptor
rather than FILE stream for stdin/stdout if built with threads
support.  At first I found this strange as FILE on NetBSD works fine
with threads, but after reflexion it makes sense.

Perhaps that a stdio stream could still be used on systems where it's
known to work with some more conditionals though.  I find
reading/writing one byte at a time quite suboptimal (however I guess
that we could provide our own buffering on top of file descriptors,
too)...
-- 
Matt