On Feb 10, 2013, at 1:26 PM, Martin Fick <mfick@xxxxxxxxxxxxxx> wrote: > On Sunday, February 10, 2013 12:03:00 pm Robert Zeh wrote: >> On Sat, Feb 9, 2013 at 1:35 PM, Junio C Hamano > <gitster@xxxxxxxxx> wrote: >>> Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: >>>> This is much better than Junio's suggestion to study >>>> possible implementations on all platforms and >>>> designing a generic daemon/ communication channel. >>>> That's no weekend project. >>> >>> It appears that you misunderstood what I wrote. That >>> was not "here is a design; I want it in my system. Go >>> implemment it". >>> >>> It was "If somebody wants to discuss it but does not >>> know where to begin, doing a small experiment like >>> this and reporting how well it worked here may be one >>> way to do so.", nothing more. >> >> What if instead of communicating over a socket, the >> daemon dumped a file containing all of the lstat >> information after git wrote a file? By definition the >> daemon should know about file writes. > > But git doesn't, how will it know when the file is written? > Will it use inotify, or poll (kind of defeats the point)? > > -Martin I was thinking it would loop on calls to stat for the file with a timeout; this is no different than what we would want to do over a socket in that we would need timeouts for network reads. But we would only be calling stat on one file, instead of the entire repo. I think we can set things up so the file read is atomic, which means we can ignore the case of a daemon crashing midway through a conversation. Robert -- 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