<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 4, 2009, at 5:30 PM, Bryan O'Sullivan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Fri, Dec 4, 2009 at 8:39 AM, Svein Ove Aas <span dir="ltr">&lt;<a href="mailto:svein.ove@aas.no">svein.ove@aas.no</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
That said.. you say you have to handle the events "fast". What happens<br>
if you don't?</blockquote><div><br></div><div>If you don't handle events quickly, they're typically thrown away by the kernel without you ever getting to read them. That is, for instance, what happens on Linux with inotify. Throwing away events means that your app's internal mirror of the filesystem state becomes wrong, which is Very Bad for most applications that care. (i.e. Ross's assertion than nothing bad will happen is generally not true.)</div></div></blockquote><div><br></div>Ah hah yeah, I meant in the context of it won't block the kernel or cause your computer to melt. It varies between applications whether dropping events is bad or not so I wasn't commenting there.</div><div><br></div><div><blockquote type="cite"><div class="gmail_quote"><div><i>However</i>, with inotify you <i>also</i> can't afford to perform a single read system call per event, because that will cause your "watch the filesystem" event to soak up most of the system's CPU time. So what you have to do is select to listen for "there's an event ready to be read", then sleep a little while, <i>then</i>&nbsp;read in the hope that many (but not too many!) events will have been queued that you can all read at once.</div>
<div><br></div><div>And at that point, you'll be getting a stale notification about a file or directory that may no longer even exist, or may have changed type. Consider: I create a file f, write data into it, rename it to g, then create a directory named f. You wake up 10 milliseconds later, and the first event you hear about is that a file named f was created.</div>
<div><br></div><div>This is all by way of saying that working with filesystem change notification interfaces is extremely subtle and tricky, enormously more so than you'd think on casual inspection. It's very easy to write a program that uses these interfaces in ways that will make it either generate garbage or consume huge amounts of CPU, and in fact the common case is to write a program that does both.</div>
</div>
</blockquote><br></div><div>Amen. I've written an application that does this kind of work using inotify and it was a <i>nightmare</i>. I think this is why fseventsd was invented for OS X, and I'm not sure if there's any linux equivalent.</div><div><br></div><div>However, if someone were to write a library that uses kqueue / inotify / win32-call-I-forget-the-name-of-from-earlier-post in a way that is both efficient and correct, that would be totally awesome.</div><div><br></div><div>-Ross</div><div><br></div><br></body></html>