On Fri, 11 Sep 2009, Jeff King wrote: > 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. You don't remember October 2005? HPA introduced it in 960decc, which has a pretty good explanation: we doesn't want to get DoS'd if clients just send SYNs. So it's supposed to time out only if we spend that long waiting for a protocol item from the client. -Daniel *This .sig left intentionally blank* -- 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