Hi, Kevin Ryde <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (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
