Re: Cannot clone redirecting stdout

From: Jeff King <peff@peff.net>
Date: Sep 11, 2009, 16:20 UTC
Message-ID: <20090911162013.GA10939@coredump.intra.peff.net>
In-Reply-To: <20090911160510.GA10848@coredump.intra.peff.net>

On Fri, Sep 11, 2009 at 12:05:10PM -0400, Jeff King wrote:

Show 9 quoted lines

> Ah. I have a theory. If I do a clone of git://gitorious.org/qt/qt.git,
> the counting/compressing stages take a long time (I timed it at 1m40
> before it actually sends any data). And looking at upload-pack.c, we
> leave the 30-second alarm set while creating the pack. Meaning we die 30
> seconds into creating the pack.
> 
> When progress is being displayed, however, the progress timer actually
> uses SIGALRM, as well. So we are constantly resetting the timer and it
> never goes off.

Hmm. Actually, this is not quite right. It looks like we call out to pack-objects as an external program, so there is no conflict with the signal. And we do proxy the output of pack-objects, which will keep our timer resetting every time we see a chunk of output. But pack-objects produces no output during the deltification phase, unless progress is turned on. So we still hit our timeout in upload-pack during that phase.

So our options are:

  1. Turn off the timer during deltification, which could mean that it
     would potentially go forever. But it's not controlled by the user.
     I think the 'timeout' feature is really about the client just
     opening the connection and sitting.

  2. Keep progress on during deltification, but just throw it away
     instead of relaying it if no-progress is in effect.

  3. Accept that hitting the timeout during deltification _should_ cause
     it to die. In that case, then the case with progress is wrong, and
     we should stop resetting the timer just because we got some
     progress output from pack-objects. But this may be redefining the
     intent of --timeout. I don't know what the original intent was, or
     what users of the feature are expecting.

-Peff