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

[Junio C Hamano <gitster@pobox.com>]

Adam Borowski <kilobyte@angband.pl> writes:

> 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...