Re: [PATCH] Add current-suspendable-io-status parameter

[Mark H Weaver <mhw@netris.org>]

Hi Nala,

Nala Ginrut <nalaginrut@gmail.com> writes:

> I think your approach works for the cases which use put-bytevector* directly.
> Are you assuming the server-core only handles suspendable-port with
> put-bytevector in http-read or http-write?
> If so, then your approach is not enough.

If you're not using 'put-bytevector', then the 'start' and 'count'
variables in {read,write}-bytes will not relate to your buffer, and
therefore will not be meaningful.

For example, suppose you use 'put-string' to write 20 thousand
characters to a socket.  While that operation is pending, presumably you
would like information on how many of those characters have been
written, i.e. you want a number in the range 0 to 20000.  Am I right?

'start' and 'count' from {read,write}-bytes will not tell you how much
of that string has been written.  What will happen is this: the initial
characters of the string will be converted into the port encoding, as
much as will fit in the port "auxiliary write buffer", which is 256
bytes long.  Those ~256 bytes will be written using 'write-bytes', so
'start' will typically be 0 and 'count' will be a number <= 256.  That
will happen repeatedly until the entire string has been written.

Do you see now why your approach will not work?

In general, the I/O operations visible to the user may be broken up into
smaller operations within Guile.  If we are to provide I/O progress
information, we must provide information that relates to the operations
that the user knows about.  The fundamental problem with your proposed
patch is that it does not do that.

> That is to say, every I/O operation should have the ability to return
> the current I/O status for the scheduler.

It's a reasonable wish.  You'd like to provide progress information for
all I/O operations in a single stroke, without having to write something
like 'put-bytevector*' for each I/O primitive.

It would be nice if 'start' and 'count' from {read,write}-bytes were
able to provide universally-applicable progress information for any I/O
operation.  I've explained above why it doesn't.

I thought a bit about what a universally-applicable progress indicator
would look like, and I can't think of a good way to do it.  It might be
better to start by thinking about some specific examples of other I/O
operations.

I've already given the example of writing a string, but let's think a
bit more about that case.  For textual I/O, arguably the progress
information should be given as a number of *characters* written.  We
could also in theory provide the number of bytes written, but we can't
say how many bytes remain to be written, or what the total number of
bytes will be.  We can only say how many *characters* remain to be
written.

What about when we write something more structured, such as writing a
large S-expression using 'write', or serializing XML from SXML.  In
those cases, it's even more obvious that we have no idea how many bytes,
nor how many characters will be written, until we're finished.  Both of
these operations result in a large number of small write operations, and
clearly, status information for each of those small write operations is
not useful.

In your opinion, how should I/O progress information be represented in
these cases?

Can you see now why your approach doesn't work for most I/O operations?

     Regards,
       Mark