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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 16, 2016, 18:15 UTC
Message-ID: <xmqqpolvqoka.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <17709AFF-3C2D-4EC0-97DC-BD750F514D0B@gmail.com>

Lars Schneider <larsxschneider@gmail.com> writes:

Show 7 quoted lines

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