kqueue is the "low level" interface, but requires that you handle all file system events as they happen, and fast. There is a higher level interface called fsevents (with accompanying daemon fseventsd) which allows you a more calm way to read the file system events. http://developer.apple.com/mac/library/documentation/Darwin/Conceptual/FSEve... I think launchd just happens to have an integration to kqueue or fseventsd, I'm not sure launching a program every time a file changes would be the best thing :-) -Ross On Dec 4, 2009, at 11:08 AM, David Leimbach wrote:

d

On Thu, Dec 3, 2009 at 7:55 PM, Gregory Collins

...

wrote: Conal Elliott writes:

...

I'd like to make some FRPish toys that keep files updated to have functional relationships with other files. hinotify looks like just the sort of underlying magic I could use for efficient implementation on linux. Is there any support for mac os x? Could support be either added to hinotify or maybe inotify and a mac-friendly library be abstracted into a common Haskell interface? I'm fine with an imperative interface, since I can abstract into a functional library, which I guess would be a sort of persistent simplified FRP.

On Mac & BSD you have to use kqueue, and on Windows it's ReadDirectoryChangesW. A platform-agnostic Haskell library for detecting filesystem change notifications is something that I would really appreciate!

launchd does everything on mac os x, like literally everything. My mother said if I can't say something good about someone or something then don't say anything at all, and in this case, I'm taking her advice on what I think about launchd, however if you click the link below you might get an idea of how that works on Mac OS X.

http://stackoverflow.com/questions/1515730/is-there-a-command-like-watch-or-...

Dave

G -- Gregory Collins _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Well, I don't think anything bad will happen, but I think I remember there being no/little buffering, so your program had to be responsive if you wanted to get the events. fseventsd is a daemon on top that keeps logs, so you can read them at leisure. I'm sorry I can't find the original article I had read to learn this, otherwise I'd link you directly so you could make your own judgements. I think the decision between the two is primarily based on your use case. If you are intended to run continuously and handling each event will probably not use that many resources (as to not bog down the system as you receive many file system events), and you need real-time tracking, kqueue is for you. Conversely, if you need to know things changed soon after, but not immediately, and especially if you don't want to be running continuously, then fseventsd is for you. This is my understanding, not having used either directly (I've only used inotify on linux). -Ross On Dec 4, 2009, at 11:39 AM, Svein Ove Aas wrote:

On Fri, Dec 4, 2009 at 5:31 PM, Ross Mellgren wrote:

...

kqueue is the "low level" interface, but requires that you handle all file system events as they happen, and fast.

For the purposes of creating a binding in haskell, my preferred way would be to use the low-level interface and build saner abstractions on top of that; it would be trivial to buffer them haskell-side.

That said.. you say you have to handle the events "fast". What happens if you don't?

-- Svein Ove Aas

On Dec 4, 2009, at 5:30 PM, Bryan O'Sullivan wrote:

On Fri, Dec 4, 2009 at 8:39 AM, Svein Ove Aas 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.)

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.

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.

Amen. I've written an application that does this kind of work using inotify and it was a nightmare. I think this is why fseventsd was invented for OS X, and I'm not sure if there's any linux equivalent. 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. -Ross

Thanks, Matt. I see libev is available via macports. - Conal On Fri, Dec 4, 2009 at 3:03 PM, Matt Morrow wrote:

Conal,

If I were looking to do this, I'd read the relevant parts of the libev code.

Matt

On 12/3/09, Conal Elliott wrote:

...

I'd like to make some FRPish toys that keep files updated to have functional relationships with other files. hinotify looks like just the sort of underlying magic I could use for efficient implementation on linux. Is there any support for mac os x? Could support be either added to hinotify or maybe inotify and a mac-friendly library be abstracted into a common Haskell interface? I'm fine with an imperative interface, since I can abstract into a functional library, which I guess would be a sort of persistent simplified FRP.

- Conal