On Tue, Mar 05, 2013 at 10:30:07AM -0300, Thiago Padilha wrote: > I'm not always sure about the meaning of client in tmux, but what needs to > hold the lock is not the tmux command that connects to the server, but the > process that is connected to the pseudo tty that is displayed by the tmux > pane(normally this will be a shell), that is why I used panes to reference > the 'object' currently locking the monitor.
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. > I have implemented something similar to monitor concept explained in > wikipedia([1]http://en.wikipedia.org/wiki/Monitor_(synchronization): > - Each monitor has one slot and two queues > - When a pane is occupying the slot, what is referenced is the pane and > the cmdq is freed so the process attached to the pseudo tty can continue > its work. > - The first queue(lock queue) is for panes waiting to occupy the monitor > slot. In this case what is referenced in the queue is the cmdq structure > - The second queue(wait queue, which is actually a stack) is for panes > waiting for a signal to occupy the monitor slot. > - The only way to enter the wait queue is by occupying the monitor slot > first, which will cause the pane to temporarily 'yield' the monitor slot > to the next pane in the lock queue and enter the wait stack. When a pane > attempts to wait, it will first acquire the monitor slot if not occupying > already. In this case the pane will also automatically release the slot as > soon as it receives the signal. > - The only way for a pane to signal others is by occupying the monitor > slot first. The signal will pop all panes from the wait stack and push > them to the front of the wait queue(a stack was used for waiting so that > the first pane to enter the stack will be the first pane in the lock queue > after the signal).**When a pane attempts to signal, it will first acquire > the monitor slot if not occupying it already. In this case the pane will > also automatically release the slot as soon as it signals. I don't think we need to be quite so complex. I think it will be sufficient just to have a single queue of waiters and wake them all up when signalled or wake the first up when the lock is released. Although I'd prefer to see wait/signal working first and then extend it to lock/unlock. > I used the name 'monitor' because it is the most complete synchronization > primitive(achieves locking, waiting and signaling) In this sense "monitor" is too technical and in the common sense it doesn't fit well. And we use it for other things (monitor-content and friends). > > On Tue, Mar 5, 2013 at 10:03 AM, Nicholas Marriott > <[2]nicholas.marri...@gmail.com> wrote: > > I haven't had a lot of time to spend on this but: > > I don't understand why you are doing anything with panes. What have > panes got to do with it? This only needs to worry about clients. Panes > can't wait for anything. > > Also we will need to change the name, I don't like "monitor", but we can > worry about that later. > > On Tue, Mar 05, 2013 at 09:47:45AM -0300, Thiago Padilha wrote: > > ** **Any chance this patch will be accepted? > > ** **I still need to tweak a few things: > > ** **- Detect when a waiting pane exits and remove it from the > queue/monitor > > ** **- Move the queue shifting to the event loop > > ** **- Handle SIGINT in the tmux client(Not sure **about this one) > > ** **I didn't manage to implement those myself, so I was hoping for > some > > ** **feedback/help > > ** **If you guys want I can recreate the patch against the current > master. > > > > ** **On Sun, Mar 3, 2013 at 7:53 PM, Thiago Padilha > <[1][3]tpadilh...@gmail.com> > > ** **wrote: > > > > ** ** **Here's a nice integration between vim and tmux for any zsh > users that > > ** ** **want to give this patch a > > ** ** **try:**[2][4]https://gist.github.com/tarruda/5051527 > > ** ** **Combined with the new zoom patch, you can get a nice 'toggle > top > > ** ** **terminal' experience. > > > > ** ** **On Tue, Feb 26, 2013 at 11:37 AM, Thiago Padilha > > ** ** **<[3][5]tpadilh...@gmail.com> wrote: > > > > ** ** ** **Here is TAILQ version of the patch, along with the event > loop > > ** ** ** **diff(which > > ** ** ** **randomly crashes the server for me again) > > ** ** ** **--- > > ** ** ** ****Makefile.am ** ** ** ** | ** 2 + > > ** ** ** ****cmd-monitor.c ** ** ** | 110 ++++++++++++++++++++++++++++ > > ** ** ** ****cmd.c ** ** ** ** ** ** ** | ** 1 + > > ** ** ** ****examples/monitor.sh | 120 ++++++++++++++++++++++++++++++ > > ** ** ** ****monitor.c ** ** ** ** ** | 206 > > ** ** ** **++++++++++++++++++++++++++++++++++++++++++++++++++++ > > ** ** ** ****tmux.c ** ** ** ** ** ** **| ** 3 + > > ** ** ** ****tmux.h ** ** ** ** ** ** **| **71 ++++++++++++++++++ > > ** ** ** ****7 files changed, 513 insertions(+) > > ** ** ** ****create mode 100644 cmd-monitor.c > > ** ** ** ****create mode 100755 examples/monitor.sh > > ** ** ** ****create mode 100644 monitor.c > > > > References > > > > ** **Visible links > > ** **1. mailto:[6]tpadilh...@gmail.com > > ** **2. [7]https://gist.github.com/tarruda/5051527 > > ** **3. mailto:[8]tpadilh...@gmail.com > > > > > ------------------------------------------------------------------------------ > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > [9]http://p.sf.net/sfu/appdyn_d2d_feb > > > _______________________________________________ > > tmux-users mailing list > > [10]tmux-users@lists.sourceforge.net > > [11]https://lists.sourceforge.net/lists/listinfo/tmux-users > > References > > Visible links > 1. http://en.wikipedia.org/wiki/Monitor_(synchronization) > 2. mailto:nicholas.marri...@gmail.com > 3. mailto:tpadilh...@gmail.com > 4. https://gist.github.com/tarruda/5051527 > 5. mailto:tpadilh...@gmail.com > 6. mailto:tpadilh...@gmail.com > 7. https://gist.github.com/tarruda/5051527 > 8. mailto:tpadilh...@gmail.com > 9. http://p.sf.net/sfu/appdyn_d2d_feb > 10. mailto:tmux-users@lists.sourceforge.net > 11. 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_feb _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
