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 19:00:02 -0400 Message-ID: <87lfzaj6ya.fsf@netris.org> References: <87pnomjcs9.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="84350"; 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 Tue May 14 05:30:03 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 1hQO8h-000Lpq-9f for guile-devel@m.gmane.org; Tue, 14 May 2019 05:30:03 +0200 Original-Received: from localhost ([127.0.0.1]:38396 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQO8g-0005cR-8q for guile-devel@m.gmane.org; Mon, 13 May 2019 23:30:02 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33886) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQO7V-00059i-UZ for guile-devel@gnu.org; Mon, 13 May 2019 23:28:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hQO7U-0007eV-Sn for guile-devel@gnu.org; Mon, 13 May 2019 23:28:49 -0400 Original-Received: from world.peace.net ([64.112.178.59]:41418) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hQJxB-0003yJ-Ox for guile-devel@gnu.org; Mon, 13 May 2019 19:01:53 -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 1hQJx9-0002wl-GY; Mon, 13 May 2019 19:01:51 -0400 In-Reply-To: <87pnomjcs9.fsf@netris.org> (Mark H. Weaver's message of "Mon, 13 May 2019 16:54:03 -0400") 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:19910 Archived-At: Hello again, Previously I wrote: > 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. I gave this some more thought, and I think I now understand why you want these values. When performing large binary I/O operations, larger than the port buffers, Guile bypasses the port buffers and passes the user's bytevector directly to {read,write}-bytes. In that case, 'start' and 'count' correspond to values that are meaningful to the user. I'd like to help you get the information you need, but I don't want to use the mechanism you proposed. In addition to the efficiency problem regarding heap allocation that I already mentioned, another problem is that it's unreliable. The 'start' and 'count' provided *might* correspond to the user's buffer, or it might not, and there's no reliable way to find out. It would encourage users to write code that depends on undocumented details of Guile's internal ports implementation. 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. 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. On the read side, we already have 'get-bytevector-some', and I plan to add 'get-bytevector-some!' soon as well. This could be used to implement progress-tracking read operations. What do you think? Regards, Mark