From: Junio C Hamano Date: Wed, 16 Nov 2016 19:19:33 GMT Subject: Re: RFC: Enable delayed responses to Git clean/smudge filter requests Message-ID: In-Reply-To: <2F93C9B4-157C-4F5C-9BD5-A67AA519757A@gmail.com> Lars Schneider writes: >> On 16 Nov 2016, at 19:15, Junio C Hamano wrote: >> >> Lars Schneider 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.