"Instantaneous Notification" on OS X

Dirkjan Ochtman dirkjan at ochtman.nl
Tue Mar 18 07:16:38 CDT 2008


Hi,

Anant Narayanan <anant <at> kix.in> writes:
> 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!

Yes, it sure is. Thanks for your interest!

> 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.

I concur.

> 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.

On the other hand, we don't have to run our own daemon, which is something of an
advantage and makes a lot of things easier.

> 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 :)

I think it's a good idea, certainly. On the other hand, given that, as was
pointed out earlier in this thread, some Python API for the FSEvents is already
available, I wonder if making inotify work on OS X 10.5 wouldn't be to little
work to do in a whole summer (we should make your project worth Google's money).
But I like that you've already done some research and seem somewhat familiar
with the topic at hand! Maybe adding 10.4 support after all would improve the
scope, or maybe the inotify extension could use some spit and polish that you
could work on. But I'd like it if Bryan O'Sullivan (who first wrote the inotify
extension) could weigh in on these things.

Again, thanks for your interest!

Cheers,

Dirkjan



More information about the Mercurial-devel mailing list