From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Add current-suspendable-io-status parameter Date: Sat, 18 May 2019 19:06:37 -0400 Message-ID: <87sgtb1hwn.fsf@netris.org> References: <87pnomjcs9.fsf@netris.org> <87lfzaj6ya.fsf@netris.org> <878sv8kcqb.fsf@netris.org> <87zhnni5aj.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="208945"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: guile-devel To: Nala Ginrut Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun May 19 01:13:47 2019 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hS8WQ-000sFa-H0 for guile-devel@m.gmane.org; Sun, 19 May 2019 01:13:46 +0200 Original-Received: from localhost ([127.0.0.1]:39651 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hS8WP-0004gH-E8 for guile-devel@m.gmane.org; Sat, 18 May 2019 19:13:45 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hS8W2-0004NN-Jh for guile-devel@gnu.org; Sat, 18 May 2019 19:13:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hS8RR-0002sw-ER for guile-devel@gnu.org; Sat, 18 May 2019 19:08:38 -0400 Original-Received: from world.peace.net ([64.112.178.59]:53578) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hS8RR-0002kX-Ad for guile-devel@gnu.org; Sat, 18 May 2019 19:08:37 -0400 Original-Received: from mhw by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hS8RF-0001qY-V8; Sat, 18 May 2019 19:08:26 -0400 In-Reply-To: (Nala Ginrut's message of "Fri, 17 May 2019 19:07:29 +0800") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 64.112.178.59 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:19926 Archived-At: Hi Nala, Nala Ginrut writes: > On Thu, May 16, 2019 at 8:59 AM Mark H Weaver 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