Re: RFH: spawning pager takes long time when when unconnected from network

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, 10 Feb 2009, Eric Raible wrote:

> On Tue, Feb 10, 2009 at 2:24 AM, Johannes Schindelin
> <Johannes.Schindelin@xxxxxx> wrote:
>
> > On Tue, 10 Feb 2009, Eric Raible wrote:
> >
> >> Johannes Sixt <j.sixt <at> viscovery.net> writes:
> >>
> >> > Do you have a directory in your PATH that points to a disconnected network
> >> > drive? Do you use the default pager settings, or did you customize the pager?
> >>
> >> All components in my path are local.
> >
> > Could you run it with GIT_TRACE=<file>?
> 
> The first thing I tried was to set GIT_TRACE=1, and it doesn't give much:
> trace: built-in: git 'diff' 'ss' '--name-only'
> trace: run_command: 'sh' '-c' 'less'
> 
> The long pause in question begins after the above output is produced
> but before the list of files is shown.  The output is identical when setting
> GIT_TRACE to a file.
> 
> When I pipe the git diff to less or set core.pager="",
> then obviously it doesn't call run_command.

You could also try to set it to /bin/false, just so you know if the delay 
is caused by the shell startup.

> Since I can't really reproduce this in the debugger (because the "bug" 
> is an intermittent delay of 3-10 seconds), I tried littering the code 
> with trace_printf's.  Didn't really help, partially because after the 
> dup2 (which is part of spawning the pager process) they don't on stdout 
> any longer.  Now that I know about setting GIT_TRACE to a file perhaps 
> this is worth trying again.
> 
> But once it started to look like the delay was in the xdiff machinery,
> I figured I was chasing a side-effect, and that the real problem was
> some interaction between the two processes.  That's when I sent
> my first RFH  to the list.

In my experience, such intermittent delays are often triggered by some 
(mostly unnecessary) calls to either DNS (which might hang for quite some 
time) or domain controllers (same).  These can be triggered by shell 
startup looking for the user or host name.

However, I am just fishing here, as I cannot begin to get an idea what is 
happening on your side.

Also, it does not help that the platform is Windows, an OS I am mostly 
unfamiliar with.  But there have to be profiling tools for that platform 
where you should be able to see what function is blocking (I assume it is 
a blocking call, of course).

Ciao,
Dscho

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux