Re: [PATCH/WIP v2 00/14] inotify support

[Duy Nguyen <pclouds@gmail.com>]

On Mon, Jan 20, 2014 at 12:04 AM, Thomas Rast <tr@thomasrast.ch> 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