From: Sam S. <sd...@gn...> - 2002-01-18 18:03:52
|
> * In message <m3z...@je...> > * On the subject of "Re: [clisp-list] socket-streams vs. two-way streams" > * Sent on 11 Jan 2002 20:03:30 -0500 > * Honorable Todd Sabin <ta...@we...> writes: > > Sam Steingold <sd...@gn...> writes: > > > > * Honorable Bruno Haible <ha...@il...> writes: > > > > > > What is wrong with buffered socket streams as they are implemented > > > now? > > > > (setq s (socket-connect 80 "www.gnu.org" :external-format :dos :buffered t)) > > (format s "GET / HTTP/1.0~2%") > > (finish-output s) > > (socket-status s) > > ==> :output > > > > i.e., there is nothing to be read from the buffered socket S. > > this is why (I think) Todd wants to separate the input and output > > streams of the sockets: he thinks that after he closes the output > > stream, the input will become available. > > (I don't think this is the case since the buffering is done by CLISP, > > not the TCP/IP stack or OS). actually, the output _is_ available, i.e., even though SOCKET-STATUS returns :OUTPUT (i.e., no :INPUT is possible), READ-LINE _will_ return right away as expected. Note that READ-CHAR-WILL-HANG-P _hangs_ on a buffered socket when it cannot return NIL: (setq s (socket-connect 80 "www.gnu.org" :buffered t :external-format :dos)) #<IO BUFFERED SOCKET-STREAM CHARACTER www.gnu.org:80> (format s "GET / HTTP/1.0~2%") (READ-CHAR-WILL-HANG-P s) __HANG__ (setq s (socket-connect 80 "www.gnu.org" :buffered t :external-format :dos)) #<IO BUFFERED SOCKET-STREAM CHARACTER www.gnu.org:80> (format s "GET / HTTP/1.0~2%") (finish-output s) (READ-CHAR-WILL-HANG-P s) NIL > The problem I have with buffered sockets is on the server side, not > the client. There's no way a server can use buffered sockets, because > it's totally impossible to read a client's requests unless they happen > to terminate on 4K boundaries (or the client closes his end of the > socket with shutdown(2) before receiving a reply). And, as I said > before, I don't really care much about buffering on input, but you > can't buffer on output unless you also buffer on input, and I do care > about buffering on output. confirmed. -- Sam Steingold (http://www.podval.org/~sds) Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp> Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/> The difference between theory and practice is that in theory there isn't any. |