>>>>> "stktrc" == stktrc <firstname.lastname@example.org> writes:
stktrc> A minor glitch in read/string-partial:
stktrc> (read-string/partial nbytes [fd/port]) ---> string or #f (procedure)
stktrc> Welcome to scsh 0.6.4 (Olin Shivers)
stktrc> Type ,? for help.
>> (read-string 0 (current-input-port))
>> (read-string/partial 0 (current-input-port))
stktrc> read/string-partial should probably be returning a "" instead of a 0.
Right. Fixed in CVS, here is the patch:
RCS file: /cvsroot/scsh/scsh-0.6/scsh/rw.scm,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- rw.scm 8 Jan 2003 17:59:48 -0000 1.6
+++ rw.scm 22 Apr 2003 16:29:45 -0000 1.7
@@ -61,7 +61,7 @@
(if (= len 0)
(let* ((buffer (make-string len))
(nread (read-string!/partial buffer fd/port)))
(cond ((not nread) #f)
stktrc> The manual says that read-string/partial is an atomic
stktrc> best-effort/forward-progress call, which means that the call will
stktrc> block until there is something to read. But read-string/partial (with
stktrc> nbytes > 0) on an (TCP) socket inport returns immediately with ""
stktrc> (empty string, which I interpret as that no data was read). It should
stktrc> have blocked AFAICT.
In scsh, the ports of a socket are made non-blocking. This is assumed
by the VM for output ports and, as these flags are shared by duped
descriptors, propagated to the input port.
As RT Happe already pointed out, non-blocking IO lets
read-string/partial return immediately.