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 <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
