> On 17 Nov 2016, at 00:46, Junio C Hamano <gits...@pobox.com> wrote: > > Jakub Narębski <jna...@gmail.com> writes: > >>> I intend to implement this feature only for the new long running filter >>> process protocol. OK with you? >> >> If I remember and understand it correctly, current version of long >> running process protocol processes files sequentially, one by one: >> git sends file to filter wholly, and receives response wholly. >> >> In the single-file filter case, git calls filter process as async >> task, in a separate thread, so that one thread feeds the filter, >> and main thread (I think?) reads from it, to avoid deadlocks. >> >> Couldn't something like this be done for long running filter process, >> via protocol extension? > > My reading of the message you are responding to is that Lars means > doing so by "implement this feature". Instead of returning the > filtered bytes, a new protocol lets his filter to say "No result yet > for you to process, ask me later".
Correct!
