Re: [RFC PATCH 2/3] run-commands: add an async queue processor

From: Stefan Beller <sbeller@google.com>
Date: Aug 21, 2015, 20:12 UTC
Message-ID: <CAGZ79katsSYno3H1+yxoKk4K-1VxH99p-F8uwaDiakeWTKs-fw@mail.gmail.com>
In-Reply-To: <20150821195135.GA26720@sigill.intra.peff.net>

On Fri, Aug 21, 2015 at 12:51 PM, Jeff King <peff@peff.net> wrote:

Show 18 quoted lines

> On Fri, Aug 21, 2015 at 12:48:23PM -0700, Stefan Beller wrote:
>
>> > Before even looking at the implementation, my first question would be
>> > whether this pattern is applicable in several places in git (i.e., is it
>> > worth the extra complexity of abstracting out in the first place). I
>> > think there are a few task-queue patterns already in git; for example
>> > the delta search in pack-objects. Is the interface given here sufficient
>> > to convert pack-objects? Is the result nicer to read? Is it as
>> > efficient?
>> >
>> > We do not need to convert all possible call-sites to the new abstracted
>> > code at once. But I find that converting at least _one_ is a good litmus
>> > test to confirm that a new interface is generally useful.
>>
>> Ok, I'll head off to convert one place.
>
> Thanks. By the way, reading over what I wrote, it sounds a little
> harsher than I meant.

It did not sound harsh at all. I was just reading an internal mailing list, which cites over generalizing as a very bad practice worse than premature optimization, so I totally understand your concern and agree.

Show 8 quoted lines

> It is not "if you do not convert an existing site,
> we cannot accept a new interface, period". But I would like at least
> some explanation as an alternative, like "I'm pretty sure we can convert
> site X to this, but it is not a good time to do so now because of Y".
> Where "Y" might be "we need to do this other refactoring work first", or
> "it would be disruptive to other work in the area".
>
> -Peff