From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Newsgroups: gmane.lisp.guile.bugs Subject: bug#39610: R6RS `flush-output-port` not playing along with `transcoded-port` Date: Mon, 23 Mar 2020 10:22:09 +0100 Message-ID: <874kufs9xa.fsf@gnu.org> References: <87d0agu2yd.fsf@londo.h.r0tty.org> <87wo8orvr9.fsf@londo.h.r0tty.org> <874kuhzj6l.fsf@gnu.org> <87r1xkj96g.fsf@r0tty.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="40597"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: 39610@debbugs.gnu.org To: Andreas Rottmann Original-X-From: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Mon Mar 23 10:23:11 2020 Return-path: Envelope-to: guile-bugs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jGJIb-000AOt-JQ for guile-bugs@m.gmane-mx.org; Mon, 23 Mar 2020 10:23:09 +0100 Original-Received: from localhost ([::1]:59144 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jGJIa-0001L8-Eb for guile-bugs@m.gmane-mx.org; Mon, 23 Mar 2020 05:23:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52990) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jGJIV-0001Kz-8t for bug-guile@gnu.org; Mon, 23 Mar 2020 05:23:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jGJIU-0007Bk-45 for bug-guile@gnu.org; Mon, 23 Mar 2020 05:23:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45473) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jGJIT-0007BY-VS for bug-guile@gnu.org; Mon, 23 Mar 2020 05:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jGJIT-0000Ub-RR for bug-guile@gnu.org; Mon, 23 Mar 2020 05:23:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Mon, 23 Mar 2020 09:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39610 X-GNU-PR-Package: guile Original-Received: via spool by 39610-submit@debbugs.gnu.org id=B39610.15849553391809 (code B ref 39610); Mon, 23 Mar 2020 09:23:01 +0000 Original-Received: (at 39610) by debbugs.gnu.org; 23 Mar 2020 09:22:19 +0000 Original-Received: from localhost ([127.0.0.1]:51446 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jGJHn-0000T7-ES for submit@debbugs.gnu.org; Mon, 23 Mar 2020 05:22:19 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37637) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jGJHl-0000Sn-KH for 39610@debbugs.gnu.org; Mon, 23 Mar 2020 05:22:18 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49468) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jGJHg-0006vs-26; Mon, 23 Mar 2020 05:22:12 -0400 Original-Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=41244 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jGJHf-0007Um-Ja; Mon, 23 Mar 2020 05:22:11 -0400 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 4 Germinal an 228 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu In-Reply-To: <87r1xkj96g.fsf@r0tty.org> (Andreas Rottmann's message of "Sun, 22 Mar 2020 23:50:47 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.io gmane.lisp.guile.bugs:9685 Archived-At: Hi, Andreas Rottmann skribis: >> Andreas Rottmann skribis: >> >>> Andreas Rottmann writes: >>> >>>> [...] I isolated the cause; the following snippet hangs on Guile 2.2 >>>> and 3.0, while it worked as expected on 2.0: >>>> >>>> ;; ------------------ >>>> (import (rnrs)) >>>> >>>> (let* ((p (pipe)) >>>> (in (car p)) >>>> (out (transcoded-port (cdr p) (make-transcoder (utf-8-codec))))) >>>> (put-datum out "foo") >>>> (flush-output-port out) >>>> (display "Should have written to pipe by now, attempting reading a b= yte\n") >>>> (display "Got") >>>> (display (get-u8 in)) >>>> (newline)) >>>> ;; ------------------- >>>> >>>> It seems the underlying port is no longer flushed to the OS, so the >>>> `get-u8` now hangs waiting for input, starting with Guile 2.2. >>>> >>> I'd like to add that this is indeed not passing data to the OS, as >>> verified by strace. Also, I have now figured out the commit introducing >>> the regression, namely 8399e7af5 ("Generic port facility provides >>> buffering uniformly"); the commit before (e8eeeeb1d) still runs the >>> above code to completion. >> >> Actually I think the code above behaves as expected. =E2=80=98pipe=E2= =80=99 returns >> buffered ports by default. When flushing the transcoded port, >> =E2=80=98transcoded_port_write=E2=80=99 is called, but then bytes writte= n to the pipe >> are buffered. >> >> The fix is to add: >> >> (setvbuf (cdr p) 'none) >> >> Does that make sense? >> > It makes sense, and I can confirm that it makes the boiled-down example > I posted work. > > However, I'm not sure it is the expected behavior. Regardless of > buffering modes used, I would expect a `flush-output-port` in a "port > stack" (as produced by `transcoded-output-port`) to propagate all the > way to the OS. It seems that was the case in Guile 2.0, as I'm pretty > sure I observed the "breaking" behavior change with 8399e7af5 applied, > and not with the commit preceding it. Port types don=E2=80=99t have a =E2=80=9Cflush=E2=80=9D operation, only =E2= =80=9Cwrite=E2=80=9D. Thus, it=E2=80=99s impossible to define a port type that would propagate flushes. There are pros and cons I guess, but it seems like a reasonable choice to me. When implementing a =E2=80=9Cproxying=E2=80=9D port type like =E2=80=98tran= scoded-port=E2=80=99 that does its own buffering, it=E2=80=99s probably OK to say that it=E2=80=99s t= he proxy=E2=80=99s responsibility to ensure there=E2=80=99s no double-buffering taking place. > If the current behavior is indeed the intended one, we should make sure > the docs somehow reflect this caveat, as I imagine it may surprise > future Guile users which happen to use its R6RS support and pipes in > combination. Maybe we should not document this specific combination but rather the more general issue? I=E2=80=99m not sure how to do that. Thoughts? Thanks, Ludo=E2=80=99.