csi on Windows, Emacs and srfi 18

[George Oliver]

hello,

I'm a new Chicken user and new to Scheme in general, and I'm working
through an issue with csi and srfi 18 in Emacs on Windows 10 (though
the same problem seems to exist with csi in the native terminal).
Basically Windows doesn't properly flush output from a non-primordial
thread. An example of what I'm trying to replicate is in this tutorial
video, https://youtu.be/eXB3I3S3vJc?t=387 , and sample code would be:

(import
  (srfi 18))

(define foo 10)

(thread-start!
 (lambda ()
   (let loop ()
     (when (< 0 foo)
       (set! foo (sub1 foo))
       (print foo)
       (thread-sleep! 1)
       (loop)))))


I think this is a general problem with Windows and was mentioned on
this list some time ago,
https://lists.nongnu.org/archive/html/chicken-users/2006-09/msg00222.html.
As a reply in that thread noted,

> This is a Windows-specific problem - isatty() returns #f on Windows inside
> emacs. I assume select() (which is AFAIK not particularly efective on 
> non-socket
> fd's under Windows) is the problem, since either -:c or
> ##sys#tty-port? -> #t should
> block the thread waiting for input on fd 0 (and thus letting other threads 
> run).

I'm interested in trying to solve this problem and I'm wondering what
input Chicken users have on possible solutions and workarounds (other
than of course not using Windows or Windows/WSL). An Emacs maintainer
commented,

> Evidently, the Scheme interpreter you run assumes it is always connected to a 
> terminal device.
> But MS-Windows doesn't have Unix PTYs, so subordinate processes are run by 
> Emacs via pipes,
> and the Scheme interpreter you are using doesn't seem to like it.

> The way to solve this is in the Scheme interpreter:
> it should provide an optional behavior whereby the interactive features work
> even if the standard streams are connected to a pipe, and it should disable 
> buffering
> of the standard streams in this case.

Is that optional behavior workable? Or perhaps there is some other
indirection that could achieve the same result.

In case it matters my ultimate goal here is to interactively develop
while the program is running.

thanks for any advice, George