如何在Raku中拦截Proc :: Async的未缓冲输出？

如何解决如何在Raku中拦截Proc :: Async的未缓冲输出？

带有类似

的代码段

# Contents of ./run
my $p = Proc::Async.new: @*ARGS;
react {
    whenever Promise.in: 5 { $p.kill               }
    whenever $p.stdout     { say "OUT: { .chomp }" }
    whenever $p.ready      { say "PID: $_"         }
    whenever $p.start      { say "Done"            }
}

执行得像

./run raku -e 'react whenever Supply.interval: 1 { .say }'

我希望看到类似的东西

PID: 1234
OUT: 0
OUT: 1
OUT: 2
OUT: 3
OUT: 4
Done

但是我看到了

PID: 1234
OUT: 0
Done

我知道这与缓冲有关：如果我将该命令更改为类似

# The $|++ disables buffering
./run perl -E '$|++; while(1) { state $i; say $i++; sleep 1 }'

我得到了想要的输出。

我知道TTY IO::Handle objects are unbuffered，并且在这种情况下，产生的进程的$*OUT不是一个。而且我已经读到IO::Pipe对象 被缓冲了，“以便没有读操作的写操作不会立即被阻塞”（尽管我不能说我完全理解这意味着什么）。>

但是无论我做了什么，我都无法获得Proc :: Async的无缓冲输出流。我该怎么做？

我尝试使用$proc.bind-stdout绑定开放的IO :: Handle，但是仍然遇到相同的问题。

请注意，执行$proc.bind-stdout: $*OUT之类的操作确实可以工作，因为Proc :: Async对象不再缓冲，但这也不是解决我的问题的方法，因为我无法在输出之前进入输出出来。它确实向我建议，如果我可以将Proc :: Async绑定到无缓冲的句柄，它应该做正确的事情。但是我也无法使它正常工作。

---

为了澄清：正如Perl示例所建议的那样，我知道我可以通过禁用将作为输入传递的命令上的缓冲来解决此问题，但是我正在寻找一种方法来从创建Proc :: Async对象。

解决方法

您可以将句柄的.out-buffer（例如$*OUT或$*ERR）设置为0：

$ ./run raku -e '$*OUT.out-buffer = 0; react whenever Supply.interval: 1 { .say }'

PID: 11340
OUT: 0
OUT: 1
OUT: 2
OUT: 3
OUT: 4
Done

,

Proc::Async本身未对接收到的数据执行缓冲。但是，生成的进程可能会根据输出到的内容来做自己的事情，这就是在这里看到的情况。

许多程序会根据输出句柄是否连接到TTY（终端）来决定其输出缓冲（除其他事项外，例如是否发出颜色代码）。假设是TTY意味着人类将要观看输出，因此延迟比吞吐量更可取，因此禁用了缓冲（或限于行缓冲）。另一方面，如果输出将发送到管道或文件，则假定延迟不是那么重要，并且使用缓冲来获得显着的吞吐量优势（更少的系统调用来写入数据）。

当我们使用Proc::Async生成某些东西时，生成的过程的标准输出绑定到管道-这不是TTY。因此，被调用的程序可以使用它来决定应用输出缓冲。

如果您愿意拥有另一个依赖关系，则可以通过调用程序。伪造TTY的东西，例如unbuffer（似乎是expect包的一部分）。这是一个遭受缓冲的程序的示例：

my $proc = Proc::Async.new: 'raku','-e','react whenever Supply.interval(1) { .say }';
react whenever $proc.stdout {
    .print
}

我们只看到0，然后必须等待很长时间才能获得更多输出。通过unbuffer运行它：

my $proc = Proc::Async.new: 'unbuffer','raku','react whenever Supply.interval(1) { .say }';
react whenever $proc.stdout {
    .print
}

意味着我们每秒看到一个数字输出。

Raku能否为这一天提供内置的解决方案？是的-通过执行unbuffer本身的“魔术”（我想分配pty-一种伪造的TTY）。这不是小事-尽管它是explored by the libuv developers；至少就MoarVM上的Rakudo而言，当有可用的libuv版本提供这种功能时，我们将对其进行公开。