Changing the way buffering of input works is not trivial because everything
possible has to be consumed before poll is called again, but checking for that
is hard because of partial escape sequences. I'll have to think about it.
On Tue, Oct 27, 2009 at 10:13:01AM +0000, Nicholas Marriott wrote:
> Hi
>
> tmux commands and output have to share the same resources and you are spending
> all of them on perl output. This applies when running anything over the
> network.
>
> tmux does very aggressively buffer so it can seem worse, ie it takes longer to
> respond to other output, and of course it continues for longer after you kill
> perl. I should probably reduce the amount it is willing to buffer so processes
> block until it is consumed, I'll see what I can do.
>
> tmux can't flush its buffers when perl dies because perl is not the owner of
> the window (your shell is), so tmux doesn't get a signal when it dies.
>
> I don't know why you mention vnc, do you mean running tmux in an xterm and
> viewing it with vnc? In that case network use is limited by how fast vnc can
> update the screen and is not related to tmux, although you may find that if
> you
> run something very update-intensive vnc becomes slower to accept key presses
> as
> well.
>
>
> On Mon, Oct 26, 2009 at 10:27:07PM -0700, ranga...@gmail.com wrote:
> > To reproduce:
> >
> > Get on a Window machine.
> > SSH into a Linux machine using Putty.
> > Run tmux on the remote.
> > Split the tmux window into two panes (one above the other)
> > You should have two shell windows now.
> > Move into lower pane
> > At the prompt type the following and hit enter: perl -e '$a=0;
> > while(1) { print "$a\n"; ++$a; }'
> >
> > The torrent of data from the perl command prevents any of Tmux
> > commands from being accepted. This is on a wifi link to the linux
> > machine.
> >
> > Even logging into the remote and killing perl doesn't help. It looks
> > like tmux buffers the output and replays it to the client. But if I
> > forcibly terminate the ssh connection, the buffered output is rapidly
> > consumed.
> >
> > Is this a known problem? Any solutions? Btw, FWIW vnc doesn't have this
> > problem.
> >
> > Sorry if it's an FAQ. Google search didn't bring any results.
> >
> > ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > tmux-users mailing list
> > tmux-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/tmux-users
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
