From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 16 Nov 2016 23:46:25 GMT
Subject: Re: RFC: Enable delayed responses to Git clean/smudge filter requests
Message-ID: <xmqq37irouni.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <5eb682e8-13cb-67f2-a8a9-ec1fa1d139c6@gmail.com>

Jakub Narębski <jnareb@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".