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

[Nala Ginrut]

Hi Mark!
Thanks for so patient reply!


On Tue, May 14, 2019 at 7:01 AM Mark H Weaver <address@hidden> wrote:
> 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.

Yes, that's exactly what I want. We need to get the progress of I/O
operation when it's blocking
so that we can compute a fair priority for the tasks.

> 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.

I'm not sure if put-bytevector-some does the work, I'll list my concerns:

1. All I/O will be managed by Guile when we enabled suspendable-port.
That is to say, from the users side, users never know their I/O
operations are blocking or not. It's transparent to users.
Guile will guarantee the I/O operations to be finished by managing all
the blocking I/O mechanisms.
Users can only interact with the task with read or write waiter, which
are registered by users themselves.
In this scenario, users are out of control of I/O operations. And they
have no way to get the progress of I/O, since there's
no way to pass this status to the waiter function except for
parameters in my patch.

2. suspendable-port module has already provided a bunch of overridden
bytevector-* functions.
However, they're hidden from users. I think it's good since the
purpose of suspendable-port is to abstract all these details from
users. Users only consider the read-waiter and write-waiter for scheduling.
If we provide the low-level bytevector functions to users to let them
do the non-blocking I/O by themselves, just like most C framework
does. Then Guile suspendable-port will lose a critical feature,
although users can still implement asynchronous non-blocking I/O by
themselves with a non-managed approach. Say, do the I/O, check result
by themselves, and do the scheduling.
Personally, I'm fine with this way, since I'm familiar with both ways.
But managed I/O of suspendable-port is a good selling point for many
inexperienced server-side developers, they can use it in Scheme just
like IOCP or AIO.

Of course, I may misunderstand your mind.
Could you elaborate more about your approach?

Best regards.