"Instantaneous Notification" on OS X

[Peter Arrenbrecht]

I have no experience with inotify, so I cannot judge whether the
per-dir FSEvents would do. I guess some people using inotify heavily
should speak up here. But if does stand a chance, I'd much prefer
something based on a public API. I presume some early experiments
would soon show if FSEvents works or whether /dev/fsevents is needed.

Are there any public repos people use inotify with to get acceptable
performance? Some stats on avg files per dir should give an early
indication.

-peo

On Tue, Mar 18, 2008 at 4:22 AM, Anant Narayanan <anant at kix.in> wrote:
> Hi,
>
>  I'm interested in applying for the "Instantaneous Notification" GSoC
>  project idea as listed on your Wiki [1]. I hope this is the right
>  place to discuss SoC project ideas!
>
>  While I'm not familiar with how notifications work in Windows, I have
>  some idea of how things are laid out in the Mac. In OS X 10.4, there
>  is no public API for filesystem changes; although /dev/fsevents is
>  available (which is what Spotlight uses). However, using the fsevents
>  file has several drawbacks (the API is private for a reason) - one
>  badly behaved client is sufficient to spoil it for everyone. The
>  kernel holds all events written to the file in a buffer until all
>  interested applications have been notified. When heavy filesystem
>  activity occurs (eg. when a huge tarball is unpacked or a large
>  application is installed), it is possible that the buffer fills up and
>  events are dropped. This method also requires us to run a daemon that
>  continuously monitors the file, lest we miss certain changes, although
>  this requirement can be overcome with 3rd party wrappers over the
>  fsevents file, like fslogger [2].
>
>  In OS X 10.5 (Leopard) however, a public API for filesystem changes
>  called FSEvents [3] has appeared. The kernel does the job of
>  continuously monitoring the fsevents file and writing them to a log,
>  so our application can start at any time and say "What's changed since
>  the last time I asked?". Also, since the API is public (i.e. meant to
>  be used), this seems like the the ideal way to go. There is no chance
>  of us missing events.
>
>  Using the FSEvents API has one disadvantage when compared to probing /
>  dev/fsvents, it notifies us of directory changes only (much like the
>  older dnotify system in Linux). We still have to scan the directories
>  FSEvents returns and compare them to our cached versions to tell the
>  difference. Hence, the speedup may not be as significant as that
>  gained by inotify on Linux.
>
>  To sum up, is an FSEvents based (hence 10.5 only) solution appear to
>  something that would interest the Mercurial project?
>  Thanks in advance for your comments :)
>
>  Regards,
>  Anant
>
>  [1] http://www.selenic.com/mercurial/wiki/index.cgi/SummerOfCode#head-6d81aaeb76c2326101997f7eb92a202f8478cb4e
>  [2] http://osxbook.com/software/fslogger/
>  [3] http://developer.apple.com/documentation/Darwin/Conceptual/FSEvents_ProgGuide/Introduction/chapter_2_section_1.html
>  _______________________________________________
>  Mercurial-devel mailing list
>  Mercurial-devel at selenic.com
>  http://selenic.com/mailman/listinfo/mercurial-devel
>