From c87187f913f853a650a00ca0328817987298f7d0 Mon Sep 17 00:00:00 2001 From: Nicholas Marriott Date: Sat, 24 Jul 2010 20:11:59 +0000 Subject: 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. --- cmd-if-shell.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'cmd-if-shell.c') diff --git a/cmd-if-shell.c b/cmd-if-shell.c index 367bb691..bf60fb23 100644 --- a/cmd-if-shell.c +++ b/cmd-if-shell.c @@ -109,8 +109,7 @@ cmd_if_shell_free(void *data) if (ctx->cmdclient != NULL) { ctx->cmdclient->references--; exitdata.retcode = ctx->cmdclient->retcode; - server_write_client( - ctx->cmdclient, MSG_EXIT, &exitdata, sizeof exitdata); + ctx->cmdclient->flags |= CLIENT_EXIT; } if (ctx->curclient != NULL) ctx->curclient->references--; -- cgit