Hi
It's not really a bug - it's just that if-shell and run-shell are always
asynchronous.
Your change fixes the case where you have a config file and create the
first session from "tmux new", which is fine as far as it goes, but it
only affects this one case.
As you say it doesn't help where I have a config file with eg:
if "[ -e foo ]" "source foo"
new
And then do "tmux attach".
I think your suggestion is to fix this by making all new-session wait
for all jobs to finish. That won't going to work, because what if I do:
if "[ -e foo ]" "source foo"
new
neww
Then my "neww" will run before "new" and fail.
In order to fix all cases I think you will need to make all if-shell and
run-shell synchronous by blocking command processing until they
complete.
To do this I think you'll need to:
- have a queue of pending commands, either a queue of struct cmd_lists
or a queue of struct cmds, not sure if it is better to queue before or
after commands sequences are split - probably after
- make commands and/or cmd_lists reference counted
- have a flag for command processing - when it is set, new commands
(passed to cmd_exec/cmd_list_exec) go onto the pending queue instead
of being processed. when the flag goes from set to cleared, the queue
is drained
- run-shell and if-shell should set the flag when they are started and
attach a callback to the job which will clear the flag it finishes
I think this should work.
On Thu, Oct 25, 2012 at 12:12:02PM +0200, Rob Hoelz wrote:
> Does anyone have any feedback on Nicholas' statement, or my own? I
> would really like this
> bug to be fixed, and I'm willing to do the fix myself, but I wouldn't
> mind a little guidance on the "right" way to do it.
>
> -Rob
>
> On 10/22/12 11:50 AM, Nicholas Marriott wrote:
> > 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 <rob@...> 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@...
> >> https://lists.sourceforge.net/lists/listinfo/tmux-users
>
|