[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reading data from a file descriptor
From: |
Andreas Rottmann |
Subject: |
Re: Reading data from a file descriptor |
Date: |
Mon, 23 Nov 2015 22:07:11 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
<address@hidden> writes:
> On Fri, Nov 13, 2015 at 10:51:58AM -0500, Mark H Weaver wrote:
>> Jan Synáček <address@hidden> writes:
>>
>> > On Sun, Nov 8, 2015 at 12:49 AM, Andreas Rottmann <address@hidden>
>> > 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/>
- Re: Reading data from a file descriptor, (continued)
- Re: Reading data from a file descriptor, Amirouche Boubekki, 2015/11/16
- Re: Reading data from a file descriptor, tomas, 2015/11/17
- Re: Reading data from a file descriptor, Chris Vine, 2015/11/17
- Re: Reading data from a file descriptor, tomas, 2015/11/17
- Re: Reading data from a file descriptor, Chris Vine, 2015/11/17
- Re: Reading data from a file descriptor, tomas, 2015/11/17
- Re: Reading data from a file descriptor, Jan Synáček, 2015/11/18
- Re: Reading data from a file descriptor, tomas, 2015/11/16
- Re: Reading data from a file descriptor,
Andreas Rottmann <=
- Re: Reading data from a file descriptor, tomas, 2015/11/24