When changing so that the client passes its stdout and stderr as well as
authornicm <nicm@openbsd.org>
Sat, 24 Jul 2010 20:11:59 +0000 (20:11 +0000)
committernicm <nicm@openbsd.org>
Sat, 24 Jul 2010 20:11:59 +0000 (20:11 +0000)
commit636a2c4a12deeb557e680184cefc52b4c791f1b8
tree0198aaf95643915c543180b6199ab8b53c0d28fd
parentb2d0b076f7adf2024c40c0050182ef06dd88f286
When changing so that the client passes its stdout and stderr as well as
stdin up to the server, I forgot one essential point - the tmux server
could now be both the producer and consumer. This happens when tmux is
run inside tmux, as well as when piping tmux commands together.

So, using stdio(3) was a bad idea - if sufficient data was written, this
could block in write(2). When that happened and the server was both
producer and consumer, it deadlocks.

Change to use libevent bufferevents for the client stdin, stdout and
stderr instead. This is trivial enough for output but requires a
callback mechanism to trigger when stdin is finished.

This relies on the underlying polling mechanism for libevent to work
with whatever devices to which the user could redirect stdin, stdout or
stderr, hence the change to use poll(2) over kqueue(2) for tmux.
usr.bin/tmux/cmd-if-shell.c
usr.bin/tmux/cmd-load-buffer.c
usr.bin/tmux/cmd-run-shell.c
usr.bin/tmux/cmd-save-buffer.c
usr.bin/tmux/server-client.c
usr.bin/tmux/server-fn.c
usr.bin/tmux/tmux.h