"Instantaneous Notification" on OS X

Aleix Conchillo Flaqué aleix at member.fsf.org
Tue Mar 18 03:01:17 CDT 2008

I guess you will already know this, but thanks to the PyObjc bindings  
the API is already available for Python.

See this example: /Developer/Examples/Python/PyObjC/FSEvents/watcher.py

I would really be interested that someone worked in this! :-)



On Mar 18, 2008, at 4:22 AM, Anant Narayanan 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

More information about the Mercurial-devel mailing list