当大量文本输出到终端时，有什么方法可以防止 tmux 冻结？

Question

在 xterm 内的 tmux 会话中，当程序生成大量输出时（例如cat very_long_file整个会话冻结了一段时间。即使我按 Ctrl-C 也没有任何中断。大概是因为 tmux 被冻结并且它没有将 Ctrl-C 转发到生成输出的程序。有什么办法可以防止这种情况发生。

Answer 1

我在 Ubuntu 12.10 上的 tmux 1.6-2 中仍然有这个问题。我发现的一种解决方法是从会话中分离（前缀 + d），然后重新附加（tmux attach，快速外壳别名的良好候选者）。看起来 tmux 实际上在幕后响应——您可以通过 ctrl-c 确认您的进程实际上已立即终止——这只是阻塞的绘图。分离立即起作用，当您重新附加时，绘图将跳到最后。

Answer 2

正确的解决方案是查看 tmux 的 c0-* 选项以尝试对输出进行速率限制。这个问题存在的根本原因是由于数据发送到终端的速度比它可以显示的速度快，所以限速是唯一的方法。

Answer 3

据我所知，在当前版本中没有办法阻止它，但一些工作正在进行中。您可以在 tmux 的邮件列表http://thread.gmane.org/gmane.comp.terminal-emulators.tmux.user/2689上找到一些补丁。

搜索网络的一个很好的关键字是“流量控制”。

Answer 4

答案https://superuser.com/a/589896/311481工作正常。我使用以下值：

setw -g c0-change-trigger 10
setw -g c0-change-interval 250

另一个提示：如果您在 tmux 中使用 ssh，请改用 mosh：http : //mosh.mit.edu/它在显示程序输出方面表现得更聪明。它尝试在适当的时候显示最后一个屏幕状态丢弃中间值。因此，如果在其中包含 mosh 会话的窗格中生成大量输出，tmux 将永远不会冻结。

与 SSH 不同，mosh 基于 UDP 的协议可以优雅地处理丢包，并根据网络情况设置帧速率。Mosh 不会填满网络缓冲区，因此 Control-C 总是可以阻止失控的进程。

因为SSP【mosh使用的状态同步协议】工作在对象层，可以控制同步的速率（也就是帧率），所以不需要把从应用程序接收到的每一个字节都发送出去。这意味着 Mosh 可以调节帧，以免填满网络缓冲区，保持连接的响应能力并确保 Control-C 始终快速运行。必须发送每个字节的协议不能这样做。

Answer 5

不幸的是，从 tmux 版本 2.1 ( changelog )开始，用于速率限制的 c0-* 选项已被删除。据我所知，自定义速率限制的唯一方法是在源代码 (tmux.h) 中更新影响它的变量：

" READ_SIZE 是从 pty（事件高水印）保存的最大数据大小。READ_BACKOFF 是等待输出到 tty 之前 pty 读取将被回退的数据量。READ_TIME 是在回退之前的多长时间如果 tty 高于 READ_BACKOFF，则下次读取（以微秒为单位）。 ”

在哪里可以找到默认值：（从 tmux v2.2 开始）：

#define READ_SIZE 1024
#define READ_BACKOFF 512
#define READ_TIME 100