Did you forget to attach the code?
On Mon, Mar 18, 2013 at 07:54:05PM -0500, Chris Johnsen wrote: > Using popen leaves the server vulnerable to "freezing up" if the > user configures a long-running command for copy-pipe (or dead > locking if the command uses a tmux command (e.g. to make a query)). > > A copy-pipe command may need certain environment variables (e.g. > xclip uses DISPLAY). With popen, the command will inherit its > environment from the server's actual environment (not even the > configurable global environment), so it could be missing important > variables. > > Although using the global environment would at least make it > possible to adjust the values that the command inherits, it might be > better to use the active session's environment. This would keep the > user from having to update (e.g.) the global DISPLAY since the > session's DISPLAY is usually automatically updated when attaching. > > Using a job instead of popen should help fix these lockup and > environment issues. > > I have prototyped some changes that do the following: > > * add a session argument to job_run, if non-NULL its environment is > added atop the global environment, it is also passed to > server_fill_environ > * pass the session to copy_window_copy_pipe, which passes it to > job_run > * in job_run, > * use the session environment, and pass it to server_fill_environ > * dup the socket to stdin (along with stdout; instead of /dev/null) > * supply a write callback for job->event > * in this new write callback > * if the output buffer is empty, shutdown the writing half of the socket > * in window_copy_copy_pipe, start a job and bufferevent_write into > its event to supply data on the command's stdin > > In most situations, the writing half of the socket will simply be > shutdown the next time the event loop runs (which fixes a potential > client-hanging problem with an unlikely command like "tmux run 'cat > /dev/stdout'"). In the case of copy-pipe, it has its data fully > prepared and stuffs it into the outbound buffer before the event > loop has a chance to run again, so shutting down the writing half > will be deferred until the outbound buffer has been drained. This is > not sufficient for long running, full duplex jobs, but it is enough > to let us send one chunk of preprepared data to the job. > > Also something that may be related: I noticed that the cmd_q commit > added "out" and "outdone" fields to struct job, but they do not > appear to be used anywhere. Was this maybe the early bits of some > more fully formed support for full duplex jobs? > > -- > Chris > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > tmux-users mailing list > tmux-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tmux-users ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
