On 1/12/21 11:50 AM, Ævar Arnfjörð Bjarmason wrote:
On Tue, Jan 12 2021, Jeff Hostetler via GitGitGadget wrote:
This series introduces a multi-threaded IPC mechanism called "Simple IPC".
This is a library-layer feature to make it easy to create very long running
daemon/service applications and for unrelated Git commands to communicate
with them. Communication uses pkt-line messaging over a Windows named pipe
or Unix domain socket.
On the server side, Simple IPC implements a (platform-specific) connection
listener and worker thread-pool to accept and handle a series of client
connections. The server functionality is completely hidden behind the
ipc_server_run() and ipc_server_run_async() APIs. The daemon/service
application only needs to define an application-specific callback to handle
client requests.
Note that Simple IPC is completely unrelated to the long running process
feature (described in sub-process.h) where the lifetime of a "sub-process"
child is bound to that of the invoking parent process and communication
occurs over the child's stdin/stdout.
Simple IPC will serve as a basis for a future builtin FSMonitor daemon
feature.
I only skimmed this so far. In the past we had a git-read-cache--daemon
-> git-index-helper[1] -> watchman. The last iteration of that seems to
be the [3] re-roll from Ben Peart in 2017. I used/tested that for a
while and had some near-production use-cases of it.
How does this new series relate to that past work (if at all), and (not
having re-read the old threads) were there reasons those old patch
serieses weren't merged in that are addressed here, mitigated etc?
1. https://lore.kernel.org/git/1402406665-27988-1-git-send-email-pclouds@xxxxxxxxx/
2. https://lore.kernel.org/git/1457548582-28302-1-git-send-email-dturner@xxxxxxxxxxxxxxxx/
3. https://lore.kernel.org/git/20170518201333.13088-1-benpeart@xxxxxxxxxxxxx/
4. https://lore.kernel.org/git/87bmhfwmqa.fsf@xxxxxxxxxxxxxxxxxxx/
I'm starting with the model used by the existing FSMonitor feature
that Ben Peart and Kevin Willford added to Git.
Item [3] looks to be an earlier draft of that effort. The idea there
was to add the fsmonitor hook that could talk to a daemon like Watchman
and quickly update the in-memory cache-entry flags without the need to
lstat() and similarly update the untracked-cache. An index extension
was added to remember the last fsmonitor response processed.
Currently in Git, we have a fsmonitor hook (usually a perl script) that
talks to Watchman and translates the Watchman response back into
something that the Git client can understand. This comes back as a
list of files that have changed since some timestamp (or in V2, relative
to some daemon-specific token).
Items [1,2] are not related to that. That was a different effort to
quickly fetch a read-only copy of an already-parsed index via shared
memory. In the last version I saw, there were 2 daemons. index-helper
kept a fresh view of the index in shared memory and could give it to
the Git client. The client could just mmap the pre-parsed index and
avoid calling `read_index()`. Index-helper would drive Watchman to
keep track of cache-entries as they changed and handle the lstat's.
I'm not familiar with [4] (and I only quickly scanned it). There are
several ideas for finding slow spots while reading the index. I don't
want to go into all of them, but several are obsolete now. They didn't
contribute to the current effort.
The Simple IPC series (and a soon to be submitted fsmonitor--daemon
series) are intended to be a follow on to FSMonitor effort that is
currently in Git.
1. Build a git-native daemon to watch the file system and avoid needing
a third-party tool. This doesn't preclude the use of Watchman, but
having a builtin tool might simplify engineering support costs when
deploying to a large team.
2. Use direct IPC between the Git command and the daemon to avoid the
expense of the Hook API (which is expensive on Windows).
3. Make the daemon Git-aware. For example, it might want to pre-filter
ignored files. (This might not be present in V1. And we might extend
the daemon to do more of this as we improve performance.)
Jeff
