On Tue, Mar 05, 2013 at 12:10:57PM -0300, Thiago Padilha wrote: > Ok, this week I will implement it > > About the command, do you prefer two separate commands for > locking/unlocking and waiting signaling? What name(s)/parameters > should the commands have? Should I use a separate file for defining > the tree/global variables(like I did with the monitor.c file)
Just one command and I think try it without the extra file and see how it looks > > I think the only real issue I have now is on how to handle pane exits, > even more now that we will use flags for locking. For example, if a > pane holding a lock exits before unlocking what can we do? Perhaps we > can also store the ref to the pane currently holding the lock so if we > detect a pane exits we can unlock. But even so, is there an easy way > to detect when a pane exits? You can't do this, you can't use the pane because you may not have a pane. What if I run the commands from outside tmux? There is no pane. Forget about panes. If I client takes a lock all you can do is mark that lock as taken, there is no context you can save that will match it up with a new client under all the circumstances that need to work. What if I do this: $ ksh -c 'env -i tmux wait -L mylock </dev/null >/dev/null 2>&1' $ tmux splitw\; run 'tmux wait -U mylock' The pane has changed, the pty is unavailable and has also changed, the environment has changed, the PPID is different. But it still needs to work. So we cannot support lock ownership or recursion, nor automatically unlock. ------------------------------------------------------------------------------ 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
