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