Re: Reading data from a file descriptor

[Andreas Rottmann <a.rottmann@gmx.at>]

<tomas@tuxteam.de> writes:

> On Fri, Nov 13, 2015 at 10:51:58AM -0500, Mark H Weaver wrote:
>> Jan Synáček <jan.synacek@gmail.com> writes:
>> 
>> > On Sun, Nov 8, 2015 at 12:49 AM, Andreas Rottmann <a.rottmann@gmx.at>
>> > wrote:
>> >
>> >     Also note that if there's no requirement to actually implement
>> >     this in
>> >     C, there's `fdes->inport' and `fdes->outport' on the Scheme level,
>> >     so
>> >     something like the following would be analogous to the C example
>> >     code
>> >     posted:
>> >     
>> >     (import (ice-9 binary-ports))
>> >     
>> >     (define (process-fd fd)
>> >     (let ((port (fdes->inport fd)))
>> >     (display "read: ")
>> >     (display (get-bytevector-n port 100))
>> >     (display "\n")))
>> >     
>> >     (process-fd (acquire-valid-fd))
>> >     
>> >
>> > This is something very similar that I ended up with. Just instead of
>> > get-byte-vector, I used read-string!/partial.
>> 
>> I would advise against using 'read-string!/partial' or any of the
>> procedures in (ice-9 rw).  This is a vestigial module from Guile 1.8
>> when strings were arrays of bytes, which they no longer are.  We should
>> probably mark them as deprecated.
>> 
>> For one thing, when we switch to using UTF-8 as the internal string
>> encoding, it will not be possible to keep 'read-string!/partial'
>> efficient.  It will necessarily have to do an encoding conversion.
>> 
>> In Guile 2+, I would advise using byte vectors when working with binary
>> data.  Portions of these can be converted to strings with a given
>> encoding if desired.  I might be able to give better advice if I knew
>> more about what you are doing here.
>
> Mark,
>
> what Jan is after (and what I'd like to have too) is something
> akin to Unix read(2) with O_NONBLOCK: provide a buffer, request
> (up to) N bytes from the file (descriptor) and get an answer
> (with possibly less bytes).
>
> I tried that a while ago and was surprised that I had to resort
> to (character) strings, with all the downsides you mention. Something
> like that for byte vectors would be awesome. Either it exists (and
> neither Jan nor me have succeeded in finding it) or it doesn't.
>
The procedure with the closest semantics is R6RS
`get-bytevector-some`. While the R6RS says it will block if no data is
available, a quick look at Guile source code seems to indicate that it
probably works with non-blocking I/O -- I'd say it should return EOF if
called on a non-readable, non-blocking port, and otherwise not block,
and return the data available. This is all just from a quick
inspection, without running any actual code.

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.xx.vu/>