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

[Duy Nguyen <pclouds@gmail.com>]

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.
-- 
Duy