statdaemon extension

[Martin Geisler]

Nicolas Dumazet <nicdumz at gmail.com> writes:

> 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'll take it that you agree with the general idea :)

>> 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?

Yeah, I thought of that... you're right about the lack of proper
documentation: the MSDN doc on ReadDirectoryChangesW is pretty brief:

  http://msdn.microsoft.com/en-us/library/windows/desktop/aa365465%28v=vs.85%29.aspx

> 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?

Yes, something like that sounds doable. I'll think about it tomorrow.

-- 
Martin Geisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120827/67ebe2d9/attachment.pgp>