"Instantaneous Notification" on OS X

Anant Narayanan anant at kix.in
Mon Mar 17 22:22:49 CDT 2008


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


More information about the Mercurial-devel mailing list