GNU bug report logs - #39610
R6RS `flush-output-port` not playing along with `transcoded-port`

Previous Next

Full log

View this message in rfc822 format

From: Andreas Rottmann <mail <at> r0tty.org>
To: 39610 <at> debbugs.gnu.org
Subject: bug#39610: R6RS `flush-output-port` not playing along with `transcoded-port`
Date: Sat, 15 Feb 2020 14:37:04 +0100

[ re-send, used gmane to post a follow-up on the initial bug report, and
  realized that this likely cannot work. Apologies if I'm wrong and this
  ends up as a duplicate. ]

Andreas Rottmann <mail <at> r0tty.org> 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 byte\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.

I'd be somewhat motivated to try coming up with a fix, and turn the
above snippet into a testcase, but I guess I could use some hinting in
the right direction.

Regards, Rotty

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.