On 07/12/2016 02:24 PM, Duy Nguyen wrote:
Just thinking out loud. I've been thinking about this more about this.
After the move from signal-based to unix socket for communication, we
probably are better off with a simpler design than the shm-alike one
we have now.
What if we send everything over a socket or a pipe? Sending 500MB over
a unix socket takes 253ms, that's insignificant when operations on an
index that size usually take seconds. If we send everything over
socket/pipe, we can trust data integrity and don't have to verify,
even the trailing SHA-1 in shm file.
I think it would be good to make index operations not take seconds.
In general, we should not need to verify the trailing SHA-1 for shm
data. So the index-helper verifies it when it loads it, but the git
(e.g.) status should not need to verify.
Also, if we have two git commands running at the same time, the
index-helper can only serve one at a time; with shm, both can run at
full speed.
So, what I have in mind is this, at read index time, instead of open a
socket, we run a separate program and communicate via pipes. We can
exchange capabilities if needed, then the program sends the entire
current index, the list of updated files back (and/or the list of dirs
to invalidate). The design looks very much like a smudge/clean filter.
This seems very complicated. Now git status talks to the separate
program, which talks to the index-helper, which talks to watchman. That
is a lot of steps!
I think we should wait until we heard from the Windows folks what the
problems with the current solution are, and see what design they come up
with.
For people who don't want extra daemon, they can write a short script
that saves indexes somewhere in tmpfs, and talk to watchman or
something else. I haven't written this script, but I don't think it
takes long to write one. Windows folks have total freedom to implement
a daemon, a service or whatever and use this program as front end. How
the service talks to this program is totally up to them. For people
who want to centralize everything, they can have just one daemon and
have the script to talk to this daemon.
I can see that getting rid of file-based stuff simplifies some
patches. We can still provide a daemon to do more advanced stuff (or
to make it work out of the box). But it's not a hard requirement and
we probably don't need to include one right now. And I think it makes
it easier to test as well because we can just go with some fake file
monitor service instead of real watchman.
I think the daemon also has the advantage that it can reload the index
as soon as it changes. This is not quite implemented, but it would be
pretty easy to do. That would save a lot of time in the typical workflow.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html