Re: [clisp-list] bug list

[Sam S. <sd...@gn...>]

> * Don Cohen <qba...@vf...3-vap.pbz> [2011-02-15 12:04:09 -0800]:
>
>   - ebadf - when sockets get RST I argue they should be treated as if
>     they got FIN, i.e., eof

I don't think RST vs FIN is a lisp issue, i.e., how do I know that - in
Lisp or C?  All I have is a file descriptor!

>   - RST on close - clisp socket streams ending with rst

Again, this sounds like an underlying protocol issue.

> I had asked as part of one of the messages on RST whether there was
> any advantage to making socket streams buffered.
> I now notice in impnotes/open.html
>   # for functions that create SOCKET:SOCKET-STREAMs and pipes, :DEFAULT
>   is equivalent to T on the input side and to NIL on the output side; it
> Is there any way to get NIL for input and T for output?

yes, I think so.
use make-stream to create two separate streams and then make-two-way-stream.

> Can the two directions be separated, e.g., so you could send bytes and
> receive characters?

same approach - make-stream with :element-type

>   if you are transmitting a lot of data then using buffering will
>   significantly speed up your i/o;
>
> Is this really true?  Why would it be?  The term "transmitting"
> suggests to me that this is true more for output than input.
> Was this the intended meaning?
> TCP does its own buffering.  I wouldn't expect clisp buffering to
> offer any advantage over that.

I think Bruno tested that 10+ years ago.
It might be different now.

> I don't yet see any way in clisp to control the size of either of
> these buffers.

I think it is hardwired to 4k, see stream.d

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final)
http://www.memritv.org http://mideasttruth.com http://ffii.org
http://palestinefacts.org http://pmw.org.il
It's not just a language, it's an adventure.  Common Lisp.