From: "Jakub Narębski" <email@example.com>
To: Lars Schneider <firstname.lastname@example.org>,
Junio C Hamano <email@example.com>
Cc: Eric Wong <firstname.lastname@example.org>, email@example.com
Subject: Re: RFC: Enable delayed responses to Git clean/smudge filter requests
Date: Wed, 16 Nov 2016 23:41:57 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
W dniu 16.11.2016 o 10:53, Lars Schneider pisze:
> On 15 Nov 2016, at 19:03, Junio C Hamano <email@example.com> wrote:
>> Lars Schneider <firstname.lastname@example.org> writes:
>>>> The filter itself would need to be aware of parallelism
>>>> if it lives for multiple objects, right?
>>> Correct. This way Git doesn't need to deal with threading...
>> * 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?
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? Namely, Git would send in an async task
content to be filtered, and filter process would stream the response
back, in any order. If it would be not enough, we could borrow
idea of channels, and be sending few files back concurrently in
parallel, as separate channels... though that would probably
require quite a bit of change in caller.
next prev parent reply other threads:[~2016-11-16 22:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-14 21:09 RFC: Enable delayed responses to Git clean/smudge filter requests Lars Schneider
2016-11-15 1:03 ` Eric Wong
2016-11-15 14:29 ` Lars Schneider
2016-11-15 18:03 ` Junio C Hamano
2016-11-16 9:53 ` Lars Schneider
2016-11-16 18:15 ` Junio C Hamano
2016-11-16 18:47 ` Lars Schneider
2016-11-16 19:19 ` Junio C Hamano
2016-11-16 22:41 ` Jakub Narębski [this message]
2016-11-16 23:46 ` Junio C Hamano
2016-11-17 9:19 ` Lars Schneider
2016-11-24 15:45 ` Lars Schneider
2016-11-28 21:48 ` Junio C Hamano
2016-11-15 18:27 ` Eric Wong
2017-01-09 20:44 ` Stefan Beller
2017-01-11 12:57 ` Lars Schneider
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).