From: Lars Schneider <larsxschneider@gmail.com>
Date: Wed, 16 Nov 2016 18:47:17 GMT
Subject: Re: RFC: Enable delayed responses to Git clean/smudge filter requests
Message-ID: <2F93C9B4-157C-4F5C-9BD5-A67AA519757A@gmail.com>
In-Reply-To: <xmqqpolvqoka.fsf@gitster.mtv.corp.google.com>


> On 16 Nov 2016, at 19:15, Junio C Hamano <gitster@pobox.com> wrote:
> 
> Lars Schneider <larsxschneider@gmail.com> writes:
> 
>>> * You'd need to rein in the maximum parallelism somehow, as you do
>>>  not want to see hundreds of competing filter processes starting
>>>  only to tell the main loop over an index with hundreds of entries
>>>  that they are delayed checkouts.
>> 
>> I intend to implement this feature only for the new long running filter
>> process protocol. OK with you?
> 
> Do you mean that a long-running filter process interacting with
> convert_to_worktree() called from checkout_entry() will be the only
> codepath that will spawn multiple processes or threads?  
> 
> That is fine, but it does not change the fact that you still need to
> limit the maximum parallelism there.

Filters using the long running protocol are spawned only once by Git. 
The filter process would get all the smudge requests via the pipe
protocol and is supposed to manage the parallelism on its own.

- Lars