On Tue, May 13, 2014 at 4:10 PM, Duy Nguyen <pclo...@gmail.com> wrote: > On Tue, May 13, 2014 at 9:06 PM, Erik Faye-Lund <kusmab...@gmail.com> wrote: >> On Tue, May 13, 2014 at 3:49 PM, Duy Nguyen <pclo...@gmail.com> wrote: >>> On Tue, May 13, 2014 at 8:37 PM, Erik Faye-Lund <kusmab...@gmail.com> wrote: >>>> On Tue, May 13, 2014 at 3:01 PM, Duy Nguyen <pclo...@gmail.com> wrote: >>>>> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
