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
