Re: [PATCH 2/3] Add read-cache--daemon

> On Tue, May 13, 2014 at 9:06 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>> On Tue, May 13, 2014 at 3:49 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>>> On Tue, May 13, 2014 at 8:37 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>>>> On Tue, May 13, 2014 at 3:01 PM, Duy Nguyen <pclouds@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.