xterm 内の tmux セッションで、プログラムが大量の出力を生成すると (cat very_long_fileセッション全体がしばらくの間フリーズします。Ctrl-C を押しても何も中断されません。おそらく、tmux がフリーズし、出力を生成するプログラムに Ctrl-C を転送していないためです。これを防ぐ方法はありますか。
答え1
正しい解決策は、tmux の c0-* オプションを調べて、出力のレート制限を試みることです。この問題が発生する原因は、データが端末に送信される速度が端末の表示速度よりも速いためであり、レート制限が唯一の方法です。
答え2
Ubuntu 12.10 の tmux 1.6-2 でもこの問題は発生します。私が見つけた回避策の 1 つは、セッションからデタッチ (プレフィックス + d) してから再アタッチ ( tmux attach、クイック シェル エイリアスに適した候補) することです。tmux は実際には内部で応答しているようです。プロセスが実際に ctrl-c ですぐに終了していることを確認できます。ブロックしているのは描画だけです。デタッチはすぐに機能し、再アタッチすると描画は最後までスキップされます。
答え3
私の知る限り、現在のリリースではこれを防ぐ方法はありませんが、いくつかの作業が進行中です。tmuxのメーリングリストでいくつかのパッチを見つけることができます。http://thread.gmane.org/gmane.comp.terminal-emulators.tmux.user/2689。
Web で検索するのに適したキーワードは「フロー制御」です。
答え4
残念ながら、レート制限のためのc0-*オプションはtmuxバージョン2.1（変更履歴私の知る限り、レート制限をカスタマイズする唯一の方法は、ソース コード (tmux.h) 内でそれに影響を与える変数を更新することです。
「READ_SIZE は、pty から保持するデータの最大サイズ (イベントの最高水準点) です。READ_BACKOFF は、pty の読み取りがバックオフされる前に tty に出力されるのを待機しているデータの量です。READ_TIME は、tty が READ_BACKOFF を超えた場合に、次の読み取りの前にバックオフする時間 (マイクロ秒単位) です。「
デフォルトは次の場所にあります: (tmux v2.2 以降):
#define READ_SIZE 1024
#define READ_BACKOFF 512
#define READ_TIME 100