This page is part of the web mail archives of SRFI 68 from before July 7th, 2015. The new archives for SRFI 68 contain all messages, not just those from before July 7th, 2015.
Here's a completely different question: One stumbling block for maximal performance in the Primitive I/O layer is the fact that it uses ordinary octet vectors to write into. This has two potential problems: - The octet vector may not have the optimal alignment for the underlying OS I/O. - The octet vector may be movable by the underlying GC, which is bad for OS substrates such as Windows with asynchronous I/O, which expect a buffer to stay in a fixed location. (Sebastian Egner and I came up with this issue independently.) Now, this doesn't justify introducing an entirely new type for I/O buffers, because it would mean extending the API at all levels for negligible gain in the common case. However, maybe it be worthwile to add a procedure to the Primitive I/O layer like so: (make-i/o-buffer size) -> u8vector The Primitive I/O operations would still be required to work on "ordinary" u8vectors, but could do the job more efficiently if handed one of the above. An implementation would be free to do (define (make-i/o-buffer size) (make-u8vector size)) or could supply a tuned implementation that provides proper alignment and/or locks the u8vector to a fixed location in memory. Opinions? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla