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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 13, 2014 at 4:10 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
> On Tue, May 13, 2014 at 9:06 PM, Erik Faye-Lund <kusmabite@xxxxxxxxx> wrote:
>> On Tue, May 13, 2014 at 3:49 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
>>> On Tue, May 13, 2014 at 8:37 PM, Erik Faye-Lund <kusmabite@xxxxxxxxx> wrote:
>>>> On Tue, May 13, 2014 at 3:01 PM, Duy Nguyen <pclouds@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]