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

From: Adam Borowski <kilobyte@angband.pl>
Date: May 23, 2014, 22:34 UTC
Message-ID: <20140523223437.GA4230@angband.pl>
In-Reply-To: <xmqqy4xsgome.fsf@gitster.dls.corp.google.com>

On Fri, May 23, 2014 at 02:40:41PM -0700, Junio C Hamano wrote:

Show 14 quoted lines

> 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.  This handles all cases:
* --auto in the middle of a command: the block will kick in immediately,
  effectively reverting to non-daemonized version
* --auto at the end, the user does nothing: gc will finish its work in the
  background, just as you wanted
* --auto at the end, the user starts a new write two seconds later: gc works
  in the foreground with those 2 seconds headstart

The only loss is the lack of a progress indicator, and even that can be done.

-- 
Gnome 3, Windows 8, Slashdot Beta, now Firefox Ribbon^WAustralis.  WTF is going
on with replacing usable interfaces with tabletized ones?