On Mon, Jan 20, 2014 at 12:04 AM, Thomas Rast <tr@xxxxxxxxxxxxx> wrote: > There's also the problem of ordering guarantees between the socket and > inotify. I haven't found any, so I would conservatively assume that the > socket messages may in fact arrive before inotify, which is a race in > the current code. E.g., in the sequence 'touch foo; git status' the > daemon may see > > socket inotify > < hello... > < status > > new <empty list> > touch foo > > I think a clever way to handle this would be to add a new command: > > Wait:: > This command serves synchronization. Git creates a file of its > choice in $GIT_DIR/watch (say, `.git/watch/wait.<random>`). Then it > sends "wait <path>". The watcher MUST block until it has processed > all change notifications up to and including <path>. Assuming that the time between foo is touched and the time an event is put in the daemon's queue is reasonably small, would emptying the event queue at "hello" be enough? To my innocent eyes (at the kernel), it seems inotify handling happens immediately after an fs event, and it's uninterruptable (or at least not interruptable by another user space process, I don't think we need to care about true interrupts). If that's true, by the time the "touch syscall" is finished, the event is already sitting in the daemon's queue. The problem with wait.<random> is we need to tell the daemon to expect it. Otherwise if the daemon processes the "wait.<random>" even before "wait" is sent, it would try to wait for the (lost) "wait.<random>" event forever. An extension is git touch wait.<random> regularly. Or to keep a queue of processed "wait.*" events. Both look ugly imo. Another option is send "expect wait.<random>" first, wait for ack, touch wait.<random>, then send "wait", which is too much. -- Duy -- 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