[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unbuffered socket I/O
From: |
Ludovic Courtès |
Subject: |
Re: Unbuffered socket I/O |
Date: |
Thu, 01 Mar 2007 10:10:19 +0100 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
Hi,
Kevin Ryde <address@hidden> writes:
> address@hidden (Ludovic Courtès) writes:
>>
>> (uniform-vector-read! vec port)))
>
> Slackness in the implementation of that function. It knows a size to
> read and should come out as a read() system call of that size. Yet it
> always goes through the port buffer.
I believe it's a feature, not some "slackness". ;-)
The function is meant to read from _any_ kind of input port. Thus, it
can definitely not use the `read ()' system call to that end. Instead,
it rightfully uses one of the two public functions available to read
from an arbitrary port: `scm_getc ()' and `scm_c_read ()'.
> read-string!/partial is much better in that respect. Maybe that func
> should be loosened up to work on non-fports too, that could be nice.
>
> It's a bit of a failing of the ptab port functions that there's no
> "read N bytes", but that needn't prevent uniform-vector-read! doing
> the right thing on fports.
There's `scm_c_read ()' for "read N bytes", but it translates into N
calls to `scm_getc ()'. If the port is unbuffered, then each invocation
of `scm_getc ()' translates in one `scm_fill_input ()' call, which in
turn translates in one `select ()' and one `read ()' of size 1. I think
_this_ is the issue, not the fact that `uniform-vector-read!' can read
from any kind of port.
IMO it feels wrong to dismiss the port abstraction (e.g., by testing for
fports and using fport-specific I/O methods) just to work around this
performance problem.
> Could also think if those calls should then cope with O_NONBLOCK
> too, by sleeping in select() if finding there's nothing to read yet.
> On a single read call I would say let it throw an error, but if the
> aim is to block until the requested size then it's easy enough to
> cope.
I noticed that `fport_fill_input ()' would raise an error when reading
from a non-blocking file descriptor where input is not available (i.e.,
when `read ()' returns -1 with ERRNO == EWOULDBLOCK). Thus it must be
inconvenient (at best) to use the port I/O functions on a port whose
underlying FD is in non-blocking mode. I don't know what would need to
be done to fix this.
Thanks,
Ludovic.
- Re: Unbuffered socket I/O,
Ludovic Courtès <=