Hi Nala, Nala Ginrut <nalagin...@gmail.com> writes:
> On Thu, May 16, 2019 at 8:59 AM Mark H Weaver <m...@netris.org> 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