On Tue, Mar 05, 2013 at 11:20:54AM -0300, Thiago Padilha wrote: > Ok, I your idea is simpler and it should work. mine was just a proof > of concept actually.
I suggest you extend my code to add the tree+queues and then I will apply it and then we can add locks. Or you can do both but send them as two separate diffs. In any case I'd like to have waiting first before locks because it will be simpler and easier to review. > I would like to get this on the next version(already using on my > scripts) but I'm kinda busy to reimplement right now so I will > probably do it on weekend. Do you any idea when you will freeze tmux > 1.8 features? Just so I know how much time I have. If you are going to do it within a week or so then we will wait. > > > tmux has very little influence over the program in a pseudo-tty from > > outside, about all it can do is kill and resize it. > > > > The only way it can block it is if the user runs a tmux client inside > > it. I think you are expecting this to happen, but then looking up the > > pane as well - it isn't necessary do this, you can just use the struct > > cmdq or struct client. > > > > Any association with a pane will stop this working from run-shell and > > from outside tmux entirely where the current pane may not be very > > relevant. > > Actually, I'm only holding the pane reference when locking since when > a shell manages to acquire the lock the tmux command must return > immediately, so I can't hold the cmdq from continuing. The pane > reference is kept so I know what pane is currently holding the lock > when a 'tmux unlock' command is received(or when nesting lock > commands). The cmdq/client is only held when a shell is waiting to > lock or waiting for a signal. > > Is there any other structure I can obtain from 'cmdq' that has a 1-1 > correspondence with the tty connected to the process started on the > pane? As I said I don't need to control it, just need to keep a > reference. No because the client may not be running in a pty owned by tmux, or any pty at all. I can't think of anything that will necessarily persist between two tmux clients under all circumstances. I think the best thing to do would be to not worry about ownership of locks and simply do not support recursion. So a lock is just a flag - if it is clear you set it and continue, if it is set you wait. > > Also, how could I handle premature pane exits? Eg: a shell calls tmux > wait and the pane that started it is killed. > I need this to remove/free the cmdq from the wait queue. ------------------------------------------------------------------------------ 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_feb _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
