Hi
I think all jobs run with run-shell/if-shell should be synchronous with
other commands.
This is not quite as easy to achieve however...
On Mon, Oct 22, 2012 at 11:32:28AM +0200, Rob Hoelz wrote:
> On 10/20/12 12:13 PM, Thomas Adam wrote:
> > Hi,
> >
> > On 20 October 2012 00:38, Rob Hoelz <r...@hoelz.ro> wrote:
> >> Ok, I'm going to try sending this patch in again; I was able to view it
> >> fine in my mail reader last time, but it didn't render properly in the
> >> SF web view. I have also improved the patch a bit; it should now more
> >> closely conform to the style guidelines.
> > I'm not convinced by this read()/write() addition to the server --
> > surely the client should block on client_connect() or some such
> > instead -- assuming that's desired behaviour until all jobs are done?
> >
> > Note also that because you're looking in the jobs array, are you sure
> > that having many jobs defined in one's status-{left,right} sections
> > with #(), with a low status-interval value, don't mean the server can
> > now take a long time to finish accepting connections in this case?
> > I'm not sure how much of an issue that might be, if at all, but it
> > might be worth checking.
> >
> > -- Thomas Adam
> >
> I spent the weekend thinking about this issue, and I think that the best
> solution
> (although probably not the easiest implementation-wise) would be to mark
> all jobs started from
> server creation to post-load_cfg as "startup jobs", and blocking
> non-detaching new-session commands
> from initializing their sessions until every job marked as a startup job
> has completed. This gets around
> a bug with my current implementation where a session created shortly
> after the initial one can still end
> up with an improperly initialized environment, and I don't think there
> would be problems with the server
> deadlocking. Also, the status bar jobs issue you brought up should also
> be fixed by this.
>
> Can anyone find an issue with this approach? I spent a good amount of
> time thinking about it this weekend,
> but seeing as I'm not nearly as familiar with tmux's source or inner
> workings as many of you, I could easily
> have missed something.
>
> Thanks,
> Rob
>
> ------------------------------------------------------------------------------
> 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_sfd2d_oct
> _______________________________________________
> 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_sfd2d_oct
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
