Lars Schneider <larsxschneider@xxxxxxxxx> writes: >> On 16 Nov 2016, at 19:15, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> >> Lars Schneider <larsxschneider@xxxxxxxxx> 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. Yes, I think we are on the same page. You need to be careful not to let the filter process go berserk spawning too many threads or processes.