Re: [BUG] auto-repack exits prematurely, locking other processing out

From: Junio C Hamano <gitster@pobox.com>
Date: May 23, 2014, 22:42 UTC
Message-ID: <xmqqlhtsglr9.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20140523223437.GA4230@angband.pl>

Adam Borowski <kilobyte@angband.pl> writes:

Show 18 quoted lines

> On Fri, May 23, 2014 at 02:40:41PM -0700, Junio C Hamano wrote:
>> Adam Borowski <kilobyte@angband.pl> writes:
>> > It looks like the periodic auto-repack backgrounds itself when it shouldn't
>> > do so.  This causes the command it has triggered as a part of to fail:
>> 
>> Duy, 9f673f94 (gc: config option for running --auto in background,
>> 2014-02-08) turns to be not such a hot idea.  Sure, if we kick it
>> off background after doing something heavy, immediately before
>> giving control back to the end-user, and expect that the user will
>> stay thinking without making new changes (i.e. read-only stuff like
>> "git show" would be OK), then daemonize might be a great thing, but
>> we forgot, while doing that commit, that long-running operations
>> trigger the auto gc in the middle *and* they want it finish before
>> they continue, as the purpose of gc is to help the performance
>> during their further operation.
>
> Just add a lock that's triggered by daemonize, and have things block on this
> lock.

Hmph, it defeats the whole point of running it in the background, doesn't it? How would "blocking on the lock" be different from launching "gc --auto" and waiting for it to come back?

And it would also require addition of the big-repository-lock and code to take the lock sprinkled all over the place. I am not sure if we want to go there...