On Tue, May 13, 2014 at 4:10 PM, Duy Nguyen [off-list ref] wrote:

On Tue, May 13, 2014 at 9:06 PM, Erik Faye-Lund [off-list ref] wrote:

quoted

On Tue, May 13, 2014 at 3:49 PM, Duy Nguyen [off-list ref] wrote:

quoted

On Tue, May 13, 2014 at 8:37 PM, Erik Faye-Lund [off-list ref] wrote:

quoted

On Tue, May 13, 2014 at 3:01 PM, Duy Nguyen [off-list ref] wrote:

quoted

What do you think is a good replacement for unix socket on Windows?
It's only used to refresh the cache in the daemon, no sensitive data
sent over, so security is not a problem. I'm thinking maybe just
TCP/IP server, but that's going to be a system-wide daemon.. Perhaps
the windows daemon could just monitor $GIT_DIR/index and refresh it?

Windows has support for Named Pipes, which seems like the right kind
of communication channel. However, the programming model differs quite
a bit from unix-sockets:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa365594%28v=vs.85%29.aspx

Yeah that was my first option, but if code cannot be shared to
differences then we probably should go another way. The old
FindWindow/PostMessage still works with modern Windows, right? Maybe
we could create a window with a name derived from the daemon's pid and
save the name in the index, then PostMessage can signal the daemon. On
the UNIX front, we store pid and send SIGUSR1 instead..The good thing
here is the Git side will be very simple (PostMessage vs kill).

Hmmm.... I'm a bit worried about having to load in USER32.DLL just to
read the cache that way. But it seems we already do that, thanks to
compat/poll/poll.c (it depends on DispatchMessage,
MsgWaitForMultipleObjects, PeekMessage and TranslateMessage, all from
that DLL).

Preferably, we should delay-load USER32.DLL in compat/poll/poll.c, but
if we start needing it for the reading the index, it'll be loaded by
the vast majority of processes anyway.

Thanks for the info. I'll see if we can still stick to named pipes. If
we have to load user32.dll, hopefully the gain will outweigh load time
for that dell.

I just timed it here on my system, and omitting USER32.DLL didn't gain
anything for "git --version", so I suspect I was worrying too soon.