>Given that ‘get-bytevector-n!’ already has a variant in suspendable-ports.scm, my preference would be to rewrite ‘get-bytevector-all’ in Scheme (patch attached). That way, it would naturally be suspendable. (It’s also in line with the general strategy of moving things to Scheme.)
It currently is difficult to write a correct implementation of get-bytevector-all in pure Scheme, because ‘get-bytevector-all’ needs to return a _fresh_ bytevector and could return twice (e.g. in case of system-async-mark + call-with-prompt shenanigans). I think the proposed implementation is incorrect in this way. Could be resolved with call-with-blocked-asyncs, but given the title of the patch, that’s against the point. However, given the sequential and stateful nature of ports, I don’t think it’s useful to implement support for these ‘return twice’ situations, so I think it would be best to simply adjust the documentation to disallow this situation. Since it is not unique to get-bytevector-all, maybe it could be mentioned in https://www.gnu.org/software/guile/manual/html_node/Ports.html that it isn’t allowed to put any non-pure operation (where we include allocations as a side-effect, e.g. for open-input-bytevector etc, ) related to ports in such a situations? +(define (get-bytevector-all port) + (define %initial-length 4096) + + (let read-loop ((total 0) + (result-length %initial-length) + (result (make-bytevector %initial-length))) I sense a lack of tests for the test suite ... Also, to avoid avoidable allocations and copying, it would be nice if %initial-length could be overridden (optional #:initial-length keyword argument), in case the user has a better guess available. Best regards, Maxime Devos
