Subject: Re: RFC: Enable delayed responses to Git clean/smudge filter requests

From: Junio C Hamano <[email-masked]>
Date: Wed, 16 Nov 2016 10:15:01 -0800

Lars Schneider <[email-masked]> 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.