Re: Unbuffered socket I/O

[ludovic.courtes@laas.fr (Ludovic Courtès)]

Hi,

Kevin Ryde <user42@zip.com.au> writes:

> ludovic.courtes@laas.fr (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.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel