statdaemon extension

[Nicolas Dumazet]

2012/8/27 Martin Geisler <mg at aragost.com>:
> Martin Geisler <mg at aragost.com> writes:
>
>> So even if the daemon can say that it has processed all events it was
>> notified about, then we still don't know if there is an event "on the
>> way". The gap should be really small, but I expect it to be there.
>
> I have an idea for handling this: *assuming* the OS will deliver
> filesystem events in order, then it would be enough to create an
> additional event when status starts and then wait until this event is
> seen by the daemon -- that will ensure that the daemon has seen all
> filesystem events that occured before status was called.

Well, why not! :)

>
> I've implemented this for the Windows backend and it seems to work fine,
> that is, I don't see any change in behavior or performance. The code is
> still here if anybody want to test it:
>
>   https://bitbucket.org/aragost/statdaemon
>
> I don't know if the assumption above is valid or not -- if anybody here
> is an expert on MS filesystems, then please speak up :)

In the absence of such expert, or of proper documentation, test it?
You could imagine a crazy loadtest sending gazillions of events and
one last recognizable unique event.
Run it a couple thousand times, (possibly in separate, parallel
directories / daemon-watched entities), verifying each time that the
"stopper" is always last?

Of course, many disclaimers apply, but that would be a start.

>
> --
> Martin Geisler
>
> aragost Trifork
> Commercial Mercurial support
> http://aragost.com/mercurial/



-- 
Nicolas Dumazet — NicDumZ