Well, ideally I would first try to cause the pty to block if possible,
but I have tried to do this on several occasions. It is difficult to get
the limit right because tmux can't estimate the actual network latency
or how much is buffered on the network, so the high water mark has to be
conservativ
There is a problem with buffering in control mode. This happens when a pty
produces output faster than a control client can read. The problems are:
- the tmux job grows in memory usage with no upper bound
- even an alert user can't stop an out-of-control job fast enough to avoid
having to wait for
