[Ecls-list] Problems with slime

[Ram Krishnan]

Matthew Mondor wrote:
> 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)...
>    

Did the change to use unbuffered streams appear since 9.12.3? That's the 
version I'm using, and it still uses buffered file streams.

You're correct that the right thing to do would be to use unbuffered 
file descriptors in the C layer, and do the buffering in Lisp. Of 
course, if we had that, we wouldn't need any conditional use of stdio 
streams on any platform.

-ram

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100209/13c14e77/attachment.html>