atom feed13 messages in com.selenic.mercurial-devel"Instantaneous Notification" on OS X
FromSent OnAttachments
Anant NarayananMar 17, 2008 8:22 pm 
Aleix Conchillo FlaquéMar 18, 2008 1:00 am 
Aleix Conchillo FlaquéMar 18, 2008 1:00 am 
TK SohMar 18, 2008 1:28 am 
Peter ArrenbrechtMar 18, 2008 1:39 am 
Patrick MézardMar 18, 2008 1:42 am 
Dirkjan OchtmanMar 18, 2008 5:16 am 
Vladimir MarekMar 18, 2008 6:20 am 
Matt MackallMar 18, 2008 7:50 am 
Matt MackallMar 18, 2008 7:57 am 
Bryan O'SullivanMar 18, 2008 8:32 am 
Dirkjan OchtmanMar 18, 2008 9:39 am 
Anant NarayananMar 18, 2008 12:02 pm 
Subject:"Instantaneous Notification" on OS X
From:Peter Arrenbrecht (pete@gmail.com)
Date:Mar 18, 2008 1:39:45 am
List:com.selenic.mercurial-devel

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