Hello again,
Previously I wrote:
> I also have doubts about the utility of the information provided.
> 'start' seems completely irrelevant, since it merely indicates the
> position within the read/write buffer. It's easier to make a case that
> 'count' might be relevant, but it's not a reliable indicator of the
> overall amount of pending I/O on that port. With a few exceptions,
> 'count' is normally limited to the port buffer size, and does not
> necessarily reflect the amount of I/O pending in the higher-level code.
I gave this some more thought, and I think I now understand why you want
these values. When performing large binary I/O operations, larger than
the port buffers, Guile bypasses the port buffers and passes the user's
bytevector directly to {read,write}-bytes. In that case, 'start' and
'count' correspond to values that are meaningful to the user.
I'd like to help you get the information you need, but I don't want to
use the mechanism you proposed. In addition to the efficiency problem
regarding heap allocation that I already mentioned, another problem is
that it's unreliable. The 'start' and 'count' provided *might*
correspond to the user's buffer, or it might not, and there's no
reliable way to find out. It would encourage users to write code that
depends on undocumented details of Guile's internal ports
implementation.
I guess what you want is the ability to see incremental reports on the
progress of your large I/O operations. Is that right? If we are going
to add an API for this, it needs to be reliable, and always give reports
in terms of the high-level requests that the user gave.
My preferred approach would be something like this: we could add a
'put-bytevector-some' I/O primitive which writes some bytes from a
bytevector, blocking only as needed to write at least one byte. It
would return the number of bytes written. This can be used to implement
an efficient variant of 'put-bytevector' that gives you access to the
real-time progress information.
On the read side, we already have 'get-bytevector-some', and I plan to
add 'get-bytevector-some!' soon as well. This could be used to
implement progress-tracking read operations.
What do you think?
Regards,
Mark
