[Openmcl-devel] basic-tcp-stream is not binary?

[Gary Byers]

On Tue, 30 Jan 2007, Sunil Mishra wrote:

> Hi,
>
> I'm using MCL on Intel Mac OS. My MCL build is from
> :pserver:cvs at clozure.com/usr/local/tmpcvs/openmcl-dev, revision
> tag_070117, plus the patch Gary had sent for my last problem. Now I have
> a different problem when using hunchentoot (http://weitz.de/hunchentoot/) on
> openmcl. Here's a call I traced in MCL...
>
> 0> Calling (CCL::IOBLOCK-NO-BINARY-INPUT #S(CCL::IOBLOCK :STREAM
> #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/16) #x300042B3E70D> :UNTYI-CHAR
> NIL :INBUF #<IO-BUFFER  (UNSIGNED-BYTE 8) 0/0/2048 #x300042B3E4DD>
> :OUTBUF #<IO-BUFFER  (UNSIGNED-BYTE 8) 0/0/2048 #x300042B3E43D>
> :ELEMENT-TYPE CHARACTER :ELEMENT-SHIFT 0 :CHARPOS 0 :DEVICE 16
> :ADVANCE-FUNCTION CCL::FD-STREAM-ADVANCE :LISTEN-FUNCTION
> CCL::FD-STREAM-LISTEN :EOFP-FUNCTION CCL::FD-STREAM-EOFP
> :FORCE-OUTPUT-FUNCTION CCL::FD-STREAM-FORCE-OUTPUT :CLOSE-FUNCTION
> CCL::FD-STREAM-CLOSE :INBUF-LOCK NIL :EOF NIL :INTERACTIVE T :DIRTY NIL
> :OUTBUF-LOCK NIL :OWNER NIL :READ-CHAR-FUNCTION CCL::%IOBLOCK-TYI
> :READ-BYTE-FUNCTION CCL::IOBLOCK-NO-BINARY-INPUT :WRITE-BYTE-FUNCTION
> CCL::IOBLOCK-NO-BINARY-OUTPUT :WRITE-CHAR-FUNCTION
> CCL::%IOBLOCK-WRITE-CHAR :ENCODING NIL :PENDING-BYTE-ORDER-MARK NIL
> :LITERAL-CHAR-CODE-LIMIT 256 :ENCODE-OUTPUT-FUNCTION NIL
> :DECODE-INPUT-FUNCTION NIL :READ-CHAR-WHEN-LOCKED-FUNCTION
> CCL::%IOBLOCK-TYI :WRITE-SIMPLE-STRING-FUNCTION
> CCL::%IOBLOCK-UNENCODED-WRITE-SIMPLE-STRING
> :CHARACTER-READ-VECTOR-FUNCTION
> CCL::%IOBLOCK-UNENCODED-CHARACTER-READ-VECTOR :READ-LINE-FUNCTION
> CCL::%IOBLOCK-UNENCODED-READ-LINE :WRITE-CHAR-WHEN-LOCKED-FUNCTION
> CCL::%IOBLOCK-WRITE-CHAR :READ-BYTE-WHEN-LOCKED-FUNCTION
> CCL::IOBLOCK-NO-BINARY-INPUT :WRITE-BYTE-WHEN-LOCKED-FUNCTION
> CCL::IOBLOCK-NO-BINARY-OUTPUT :PEEK-CHAR-FUNCTION
> CCL::%IOBLOCK-PEEK-CHAR :NATIVE-BYTE-ORDER T
> :READ-CHAR-WITHOUT-TRANSLATION-WHEN-LOCKED-FUNCTION
> CCL::IOBLOCK-NO-CHAR-INPUT
> :WRITE-CHAR-WITHOUT-TRANSLATION-WHEN-LOCKED-FUNCTION
> CCL::IBLOCK-NO-CHAR-OUTPUT :SHARING NIL :LINE-TERMINATION NIL
> :UNREAD-CHAR-FUNCTION CCL::%IOBLOCK-UNTYI :RESERVED2 NIL :RESERVED3 NIL))
>
> I've been looking at some of the MCL sources. basic-tcp-stream is a
> binary stream, according to the code in l1-sockets.lisp. But the ioblock
> above has :READ-BYTE-FUNCTION CCL::IOBLOCK-NO-BINARY-INPUT. This doesn't
> make sense to me. Can someone please explain this? If there's no problem
> here, I'll report what I learn here as a bug report to hunchentoot
> developers.

TCP streams are by default "bivalent" (capable of both character and
binary I/O.)  Back in the days before "basic" streams, this meant that
a TCP stream inherited both character and binary Gray stream methods
(STREAM-READ-CHAR and STREAM-WRITE-BYTE, etc.); with BASIC-STREAMs, we
try to do things like READ-CHAR and READ-BYTE without going through
method dispatch, and this now involves dispatch through the functions
in that large structure (of type CCL::IOBLOCK).  There was a bug 
(that should have been fixed about a month ago) wherein the :FORMAT
argument to MAKE-SOCKET wasn't getting passed down to the code
that actually initializes the functions in the IOBLOCK struture when
an active (:connect :active) socket was created, and this looks like
the same issue with passive sockets.

I should probably think about this harder (and think about file-sockets,
etc.) before trying to check things in to CVS, but I suspect that
changing the definition of MAKE-TCP-STREAM (in ccl/level-1/l1-sockets.lisp)
from

(defun make-tcp-stream (fd &key format ...) ...)

to

(defun make-tcp-stream (fd &key (format :bivalent) ...) ...)

will fix (this instance of) the problem.



>
> Thanks,
>
> Sunil
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>