I've written a cross-platform file watching API for Windows/OS X/Linux
before. It's no fun.
I would strongly recommend using an existing higher-level abstraction
layer because implementing this ourselves will lead to constant edge
case discovery and bug fixing. I'd like to think that any reasonably
mature abstraction layer has already solved these problems.
Facebook's watchman is an excellent project and tool. However, it
doesn't support Windows and supporting Windows is a non-goal for them.
Porting watchman to Windows would be a lot of work. Now, I'd love to see
this done because I'd love to integrate watchman into the build system
so we can do things like kick off builds in the background when a file
changes. There is also a hgwatchman Mercurial extension that makes `hg
status` and other dirstate-crawling APIs nearly instantaneous. Both are
very compelling benefits to developer productivity and would fall out
nicely if we adopted watchman in Gecko/Firefox.
libuv is a contender. Feels a bit bloaty since we won't get much use out
of most of the APIs (or could we - perhaps Necko, others could use some
of their APIs?). If we integrate libuv, we could statically link it, not
export its symbols, and hope the linker will strip enough unused code to
get it down to a respectable size.
To more directly answer your question, inotify has several limitations.
For example, there is no recursive directory watching API. To do that,
you need to register watchers on every directory and then add/remove
watchers as necessary when directories are added and removed.
Furthermore, the default limit on max inotify watchers is pretty
conservative - 1024 or so. Large directory trees (like mozilla-central)
almost certainly exhaust this limit and require the user adjust kernel
limits.
IIRC some platforms have limitations where it is possible to overflow
the watching subsystem. If there is a massive filesystem change - say a
VCS update - some changes can get dropped. If you are relying on
watching for anything more than opportunistic event reaction, your
implementation complexity quickly grows to deal with recovering from
overflow and/or memory bloat.
These advanced cases are where I believe watchman excels. Facebook
rolled out watchman side-by-side with filesystem-based `hg status` and
compared discrepancies among their developer user base until they were
confident that watchman was just as accurate as consulting the
filesystem. A basic glance at libuv's source reveals that they don't
employ these advanced discrepancy mitigation techniques. But if all you
care about is opportunistic reaction to some filesystem change, libuv's
relative primitives should be satisfactory.
On 7/2/14, 6:29 AM, David Rajchenbach-Teller wrote:
According to the manpage of fanotify, « there is no support for create,
delete, and move events, » which would make it useless for our scenario.
What kind of drawbacks are you talking about in the case of inotify? The
possible race condition that [1] attempts to solve?
Are there any build incantations needed to use glib?
Thanks,
David
[1]
https://mail.gnome.org/archives/dashboard-hackers/2004-October/msg00022.html
On 02/07/14 15:07, Mike Hommey wrote:
I don't know what the windows and osx file monitoring APIs offer. If
they have the same kind of drawbacks as inotify for recursive directory
monitoring, then it's probably fine to go with inotify, in which case
glib is the best choice, as we already depend on it.
Otherwise, I'd go with a little shim around the fanotify system calls.
There is fanotify support since glibc 2.13, but I'm not sure that's old
enough for all the systems we support. (our current glibc dependency is
on a version >= 2.7, fwiw)
Mike
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
