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

[Mark H Weaver]

Hi Nala,

Nala Ginrut <address@hidden> writes:

> On Thu, May 16, 2019 at 8:59 AM Mark H Weaver <address@hidden> wrote:
>
>> 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.
>
> At least in Artanis server-core (Ragnarok), every blocking I/O
> operation from users
> (the downstream developer of Artanis) will be scheduled by
> delimited-continuations
> with suspendable-port. I've made a lot of works to make sure users
> don't have to care about
> any blocking I/O jobs by themselves, this would be a great selling
> point of both Artanis and Guile.
>
> So even if they're trying to load/write very small bytes, the task
> continuation will be scheduled by
> suspendable-port, and it can not be changed because Guile manages all
> asynchronous I/O.
>
> Although this looks unnecessary for small bytes, we can make a fair
> scheduler to smooth the situation.
> That's why we still need to care for the small bytes I/O.

Sorry, I failed to communicate clearly.  I agree that we need to care
about small I/O operations.

When I wrote that "status information for each of those small write
operations is not useful", I meant, for example, that if we are writing
a large S-expression containing nested list structure with 20 thousand
symbols, it is not useful to find out that "we have written 5 out of 18
bytes [in the current symbol]", if we do not also know which symbol is
the "current symbol".

Similarly, if we write a string containing 20 thousand characters, it is
not useful to find out that "we have written 30 out of 254 bytes [from
the auxiliary write buffer]", if we do not also know how much of the
string we have written.

That's the kind of information that your proposed mechanism would
provide, and that I said is "not useful".

If you disagree, please try the following exercise: show me code that
uses your proposed mechanism and suspendable ports to provide real time
reports of what percentage of a string has been written, e.g. when using
'put-string'.  Verify that it works by writing a large string (~100
million characters) over a bandwidth-limited port with UTF-8 encoding,
such that it takes at least 10 seconds to write the entire string.

      Regards,
        Mark