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: Mon, 13 May 2019 16:54:03 -0400 Message-ID: <87pnomjcs9.fsf@netris.org> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="125026"; 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 Mon May 13 22:56:40 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 1hQHzy-000WNR-BK for guile-devel@m.gmane.org; Mon, 13 May 2019 22:56:38 +0200 Original-Received: from localhost ([127.0.0.1]:34878 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQHzx-0004AC-7o for guile-devel@m.gmane.org; Mon, 13 May 2019 16:56:37 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:45769) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQHzt-00049y-HT for guile-devel@gnu.org; Mon, 13 May 2019 16:56:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hQHzT-0004M7-Pf for guile-devel@gnu.org; Mon, 13 May 2019 16:56:10 -0400 Original-Received: from world.peace.net ([64.112.178.59]:41176) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hQHzQ-0004Eh-43 for guile-devel@gnu.org; Mon, 13 May 2019 16:56:04 -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 1hQHzE-0001xF-2q; Mon, 13 May 2019 16:55:52 -0400 In-Reply-To: (Nala Ginrut's message of "Mon, 13 May 2019 18:54:38 +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:19908 Archived-At: Hi Nala, Nala Ginrut writes: > Here's a patch to add current-suspendable-io-status: > Its result is a pair: (finished-bytes . rest-bytes) > > This is useful for designing a proper scheduler algorithm for > suspendable I/O operations. > For example, the server-core based on delimited-continuation can > compute a priority based on this status to decide how to schedule the > suspended task. I'm not inclined to apply this patch. It would entail adding heap allocation to a low-level I/O procedure that otherwise need not perform any allocation. Heap allocation happens both in 'cons' and in 'parameterize'. We should try hard to avoid unnecessary complications in these low-level routines. I also have doubts about the utility of the information provided. 'start' seems completely irrelevant, since it merely indicates the position within the read/write buffer. It's easier to make a case that 'count' might be relevant, but it's not a reliable indicator of the overall amount of pending I/O on that port. With a few exceptions, 'count' is normally limited to the port buffer size, and does not necessarily reflect the amount of I/O pending in the higher-level code. If you'd like to use parameters to communicate pending I/O size to your scheduler, I think it would be better to use 'parameterize' in your own higher-level code, where you have the best knowledge of how much I/O will need to be done. If you still believe that your proposed patch is the best approach, and that the benefit of your scheduling algorithm outweighs the cost of adding these complications and heap allocations to our low-level I/O procedures, can you help me to understand why? Can you explain the theory behind your scheduling algorithm? Regards, Mark