adding Windows support to the inotify extension

Idan K idankk86 at gmail.com
Sat Oct 2 13:34:55 CDT 2010


Hi,

I've been wanting to add Windows support to the inotify extension for quite
some time now and I had some spare time this weekend to get familiar with
the code.
I have done preliminary work (just to get something working) but before I
dive in I thought it would be wise to come here and ask for advice.

Overall, the extension is pretty well written (the authors must have had
other platforms in mind when working on this), but still the extension is
currently using a few platform specific features that would need to be
changed:
(1) Unix sockets to communicate between the server and the client.
(2) Usage of select/poll with Linux's inotify system calls to receive
filesystem events. The file descriptors returned from inotify are registered
to a polling object and are polled for changes.

Regarding the client, it doesn't look like it's gonna need any major changes
other than the socket thing.

Solving (1) is relatively easy if we switch to regular sockets (tcp/udp).
It's worth checking how well this fares with security mechanisms in Windows
like UAC, Windows Firewall etc., but I think since this is all local we
should be okay.
(2) will have to be rewritten. To listen to filesystem events there's the
ReadDirectoryChangesW [1], and to enable proper shutdown this will be
used asynchronously with a shutdown event that will be set when the server
wants to shutdown.

I would like to be as close as possible to the linux server implementation,
but since select/poll isn't supported on Windows I'm not sure if it's
possible, maybe if we abstract it somehow but I don't know if it's worth
it.
Also, there are a few things that might be worth moving from linuxserver.py
to server.py to prevent code duplication (one thing that comes to mind atm
is the special treatment to events that happen under the .hg dir, causing
the server to ignore events and until .hg/wlock is deleted and to call
dirstate.invalidate).

A problem that's worth discussing right now is the possible loss of events
using ReadDirectoryChangesW (see [2], [3], [4] for discussions). I couldn't
find solutions in terms of using the API differently.
Perhaps we could identify (not sure how) such scenarios (which should be
quite rare for the common user) and fall back to regular "hg status" for a
short period of time?

That's all for now, thank you.

idan

[1] http://msdn.microsoft.com/en-us/library/aa365465(VS.85).aspx
[2]
http://stackoverflow.com/questions/57254/how-to-keep-readdirectorychangesw-from-missing-file-changes
[3]
http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/4465cafb-f4ed-434f-89d8-c85ced6ffaa8/
[4]
http://qualapps.blogspot.com/2010/05/understanding-readdirectorychangesw.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20101002/a430ad2a/attachment.htm>


More information about the Mercurial-devel mailing list