>>>>> "RT" == RT Happe <rthappe@web.de> writes:
RT> On Thu, 2 Jan 2003, Martin Gasbichler wrote:
>> The file doc/io.txt contains a description of the I/O system of Scheme
>> 48. It doesn't contain a direct specification of the character
>> representation either but it mentions the procedure read-block from
>> i/o which can be used to read into a byte-vector. There should
RT> io.txt should mention that the COUNT argument of READ-BLOCK may be
RT> symbolic:
RT> * count integer >= 0 ==> get COUNT bytes/chars, maybe block;
RT> * count = 'any ==> get at least one, maybe block, or more
RT> * count = 'immediate ==> get what's available but don't block.
RT> And that was an unfortunate design decision: the COUNT mixes numbers and
RT> politics, and doesn't let us call for at most n bytes / not blocking, let
RT> alone for at least n0 bytes, possibly blocking, at most n1 bytes, not
Well, there could be a richer interface to the VM instruction, but in
the end, it's only Unix ;-)
RT> blocking. As a result, the READ-STRING!/PARTIAL procedure in scsh/rw.scm
RT> cannot READ-BLOCK the input directly into the argument string, but has to
RT> allocate, copy, and throw away a buffer string. Not really what the !
RT> suggests. Better make READ-STRING/PARTIAL do the reading, and let R-S!/P
RT> call it and copy the result into its argument, than the wasteful other way
RT> round.
I decoupled read-string/partial from read-string!/partial and try to
use the string as the buffer for read-block if the start index is 0.
RT> By the way, the implementation of R-S!/P in scsh/rw.scm (0.6.3 beta) looks
RT> suspect to me. It basically calls READ-BLOCK with COUNT :=
RT> (if (> (byte-vector-length (port-buffer fd/port)) 1) 'any 'immediate)
RT> Problems may arise when
RT> * the requested #bytes = 0 and the port-buffer is long (COUNT = 'ANY).
RT> RSP should return 0, but may block.
Right, I must have overlooked this case.
RT> * #bytes > 0 and the buffer-port is short (COUNT = 'IMMEDIATE).
RT> RSP should get at least one character, but may not and return 0, if the
RT> buffer is (zero-sized or) empty and the input device blocks.
Hmm, I think I mixed up non-blocking with non-buffering.
--
Martin
|