On Fri, Sep 11, 2009 at 12:05:10PM -0400, Jeff King wrote:
> 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
--
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