On Fri, Dec 4, 2009 at 8:39 AM, Svein Ove Aas <svein....@aas.no> wrote:
> > That said.. you say you have to handle the events "fast". What happens > if you don't? 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.) *However*, with inotify you *also* 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, *then* read in the hope that many (but not too many!) events will have been queued that you can all read at once. 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. 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.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe