On 12:57 am, a...@pythoncraft.com wrote:
In article <d103be2b-3f1e-
46f3-9a03-46f7125f5...@r5g2000yqi.googlegroups.com>,
Nicolas Dumazet <nicd...@gmail.com> wrote:
On Sep 3, 10:33=A0pm, a...@pythoncraft.com (Aahz) wrote:
I'm curious why you went with FSEvents rather than kqueue. My company
discovered that FSEvents is rather coarse-grained: it only tells you
that
there has been an event within a directory, it does *not* tell you
anything about the change!
It depends what you want to do with your events. In my case, knowing
that an event occurred in a directory is sufficient because I already
know the state of the directory. If you look in the examples/ folder,
(watcher) you'll find that with very little work, you can maintain a
directory snapshot in memory and compare it against the new state of
the directory to know exactly what happened, when necessary.
Thanks!
kqueue has the limitation that kern.kq_calloutmax is usually set
at 4096. Meaning that one could not use this on a big (Mercurial)
repository with 5k files. FSEvents on the other hand saves us the
trouble to have to register each file individually. Also, I am not
quite sure if we can use kqueue to register a directory, to be warned
when a file is created in this directory.
<sigh> %(obscenity)s I didn't realize that you had to register each
file individually with kqueue. We were hoping to avoid having to write
watcher code because that is not reliable for renames (especially
multiple renames in quick succession).
Maybe we'll try using /dev/fsevents directly....
Just a guess, but since the kqueue interface is based on file
descriptors, not on file names, following renames reliably shouldn't be
a problem with it. If someone knows about this for sure though, it'd be
nice to hear about it. :) All of the kqueue documentation I've seen has
been rather incomplete.
Jean-Paul
--
http://mail.python.org/mailman/listinfo/python-list
